Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Minutes
    2. Acceptance of GNSO2 Review Working Group's Implementation Final Report
    3. Consideration of the At-Large Advisory Committee Detailed Implementation Plan
    4. FY20 IANA Operating Plan and Budget
    5. October 2021 ICANN Meeting Venue Contracting
    6. Contract Renewal and Disbursement for ERP Initiative (Oracle Cloud)
    7. Reaffirming the Temporary Specification for gTLD Registration Data
  2. Main Agenda:
    1. Delegation of the موريتانيا. country-code top-level domain representing Mauritania in Arabic Script to Université de Nouakchott Al Aasriya
    2. Delegation of the .SS (South Sudan) country-code top-level domain to the National Communication Authority (NCA)
    3. GAC Advice: Barcelona Communiqué (October 2018)
    4. Adoption of GNSO Consensus Policy relating to Certain Red Cross & Red Crescent Names at the Second Level of the Domain Name System
    5. Board Committee Membership and Leadership Changes
    6. Consideration of Reconsideration Request 16-11: Travel Reservations SRL, Famous Four Media Limited (and its subsidiary applicant dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, and Radix FZC (and its subsidiary applicant dot Hotel Inc.) (.HOTEL)
    7. Consideration of Reconsideration Request 18-9: DotKids Foundation (.KIDS)
    8. Consideration of Reconsideration Request 16-12: Merck KGaA (.MERCK)
    9. AOB

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2019.01.27.01), the Board approves the minutes of the 25 October Regular and Organizational Meetings of the ICANN Board and the 6 November Special Meeting of the ICANN Board.

    2. Acceptance of GNSO2 Review Working Group's Implementation Final Report

      Whereas, as part of the second review of the Generic Names Supporting Organization (GNSO), on 3 February 2017 the Board accepted the GNSO Review Implementation Plan and directed the GNSO Council to provide the Board with regular reporting on the implementation efforts.

      Whereas, the GNSO Review Working Group, with GNSO Council approval and oversight, provided the Board via the Organizational Effectiveness Committee (OEC) with semi-annual updates on the progress of implementation efforts until such time that the implementation efforts concluded.

      Whereas, the OEC monitored the progress of implementation efforts via the semi-annual implementation reports and recommends that the Board accept the Implementation Final Report of the second GNSO Review issued by the GNSO Review Working Group and approved by the GNSO Council on 16 August 2018.

      Resolved (2019.01.27.02), the Board acknowledges the GNSO Review Working Group's hard work and thanks them for producing the report of implementation of recommendations to improve the GNSO's effectiveness, transparency, and accountability, in line with the proposed timeline as set out in the adopted GNSO Review Implementation Plan.

      Resolved (2019.01.27.03), the Board accepts the GNSO2 Review Implementation Final Report of the second GNSO Review issued by the GNSO Review Working Group, which marks the completion of this important review. The Board encourages the GNSO to continue monitoring the impact of the implementation of the recommendations from the second Review of the GNSO as part of its continuous improvement process.

      Rationale for Resolutions 2019.01.27.02 – 2019.01.27.03

      Why is the Board addressing the issue?

      ICANN organizes independent reviews of its supporting organizations and advisory committees as prescribed in Article 4 Section 4.4 of the ICANN Bylaws, to ensure ICANN's multistakeholder model remains transparent and accountable, and to improve its performance.

      This action completes the second review of the GNSO and is based on the Implementation Final Report as adopted by the GNSO Council, the final report of the independent examiner, Westlake Governance, as well as the GNSO Review Working Group's (WG) assessment of the recommendations as adopted by the GNSO Council. Following the assessment of all pertinent documents and community feedback by the OEC, the Board is now in a position to consider and accept the Implementation Final Report.

      The Board, with recommendation from the Organizational Effectiveness Committee of the Board (OEC), considered all relevant documents, including the final report, the GNSO Review Working Party Feasibility Assessment and Prioritization of Recommendations by Independent Examiner ("Feasibility Assessment"), and accepted the final report issued by the independent examiner on 25 June 2016. The Board adopted the Feasibility Assessment, except recommendations 23 and 32. Additionally, the Board directed the GNSO Council to: draft an implementation plan for the adopted recommendations with a realistic timeline that took into account the continuously high community workload and consideration of the prioritization proposed by the WG; publish the plan no later than six (6) months after the Board's adoption of the Feasibility Assessment; ensure that the implementation plan includes definitions of desired outcomes and a way to measure current state as well as progress toward the desired outcome; and report back regularly to the Board on its implementation progress.

      On 3 February 2017, the Board accepted the Implementation Plan provided by the WG and approved by the GNSO Council on 15 December 2016, and directed the WG to provide semi-annual updates to the OEC until such time that the implementation efforts have concluded.

      What is the proposal being considered?

      The proposal being considered is that the Board accepts the WG's Implementation Final Report, adopted by the GNSO Council, and considered by the OEC.

      Which stakeholders or others were consulted?

      The Board, through the OEC, consulted with the GNSO Review Working Group, who was responsible for the implementation, and recommended good practices for conducting effective reviews on a timely basis and monitored the progress of the review as well as the progress of the implementation of review recommendations.

      What concerns, or issues were raised by the community?

      The implementation work conducted by the GNSO followed its standard practices to promote transparency and accountability. No concerns were voiced by the community.

      What significant materials did the Board review?

      The Board reviewed relevant Bylaws sections, Organizational Review Process documentation, GNSO Review Recommendations Implementation Plan, and the GNSO Review Working Group's Implementation Final Report.

      What factors did the Board find to be significant?

      The Board found several factors to be significant, contributing to the effective completion of the implementation work:

      • Convening a dedicated group that oversees the implementation of Board-accepted recommendations
      • An implementation plan containing a realistic timeline for the implementation, definition of desired outcomes and a way to measure current state as well as progress toward the desired outcome
      • Timely and detailed reporting on the progress of implementation

      Are there positive or negative community impacts?

      This Board action is expected to have a positive impact on the community by acknowledging and highlighting an effective completion of implementation of GNSO Review Recommendations.

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

      This Board action is anticipated to have no fiscal impact as the implementation efforts have successfully concluded. The ramifications on the ICANN organization, the community and the public are anticipated to be positive, as this Board action signifies an important milestone for organizational reviews and self-governance of ICANN.

      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 commitment pursuant to section 4.1 of the Bylaws to continue reviewing that entities within ICANN have an ongoing purpose, and to improve the performance of its supporting organizations and advisory committees. This action will serve the public interest by fulfilling ICANN's commitment to continuous review of its components to confirm that where people engage with the ICANN community support the purposes and expectations of that engagement.

      Is public comment required prior to Board action?

      No public comment is required.

    3. Consideration of the At-Large Advisory Committee Detailed Implementation Plan

      Whereas, ICANN Bylaws Article 4, Section 4.4 calls on the ICANN Board to "cause a periodic review of the performance and operation of each Supporting Organization, each Supporting Organization Council, each Advisory Committee (other than the Governmental Advisory Committee), and the Nominating Committee by an entity or entities independent of the organization under review. The goal of the review, to be undertaken pursuant to such criteria and standards as the Board shall direct, shall be to determine (i) whether that organization has a continuing purpose in the ICANN structure, and (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness."

      Whereas, the independent examiner of the At-Large Review produced a Final Report in February 2017. That report was received by the Board in June 2018, and at the same time the Board accepted the At-Large Review Recommendations Feasibility Assessment & Implementation Plan and the At-Large Review Implementation Overview Proposal as approved by the ALAC.

      Whereas, in response to that June 2018 resolution, the At-Large Review Implementation Working Group was created. That Working Group developed and approved the At-Large Review Implementation Plan (the "Implementation Plan") on 19 November 2018, which was endorsed by the ALAC endorsement on 27 November 2018.

      Resolved (2019.01.27.04), the Board acknowledges the At-Large Review Implementation Working Group's work and thanks the members of that Working Group for their efforts.

      Resolved (2019.01.27.05), the Board accepts the At-Large Review Implementation Plan, including the phased approach contained within. The Board acknowledges that more details with regard to implementation details may be required for implementation of Priorities 2 and 3 activities.

      Resolved (2019.01.27.06), the Board directs the At-Large Review Implementation Working Group to provide updates to the OEC every six months. Those bi-annual updates shall identify achievements as measured against the existing implementation plan, as well as details on future implementation plans. It is during these updates that the At-Large Review Implementation Working Group shall provide more details on implementation progress, and measurability. The OEC may request interim briefings if deemed necessary.

      Resolved (2019.01.27.07), that any budgetary implications of the At-Large Review implementation shall be considered as part of the applicable annual budgeting processes.

      Rationale for Resolutions 2019.01.27.04 – 2019.01.27.07

      To ensure ICANN's multistakeholder model remains transparent and accountable, and to improve its performance, ICANN organizes independent reviews of its supporting organizations and advisory committees as prescribed in Article 4 Section 4.4 of the ICANN Bylaws. The second At-Large started in 2016 and the independent examiner presented its Final Report in May 2017.

      The At-Large Review Implementation recommendations as noted in the At-Large Review Implementation Overview Proposal have the potential to advance ICANN's transparency and accountability objectives and have been considered carefully by the Board's Organizational Effectiveness Committee as well as by the full Board.

      The Board resolution will have a positive impact on ICANN and especially the ALAC and At-Large community as it reinforces ICANN's and the ALAC and At-Large community's commitment to maintaining and improving its accountability, transparency and organizational effectiveness throughout the implementation process.

      Due to the number of recommendations that need to be implemented, the Board supports the approach by priorities as laid out in the Implementation Plan (Exhibit A). This will allow the community time to refine details as the implementation process proceeds– especially during Priority 2 and 3 activities set out in that Implementation Plan.

      Some recommendations – especially those foreseen to be implemented under Priority 2 and 3 activities – may benefit from additional details regarding their exact implementation. Due to the difficulty to predict these issues months in advance, the Board supports the idea that the At-Large Review Implementation Working Group provides updates bi-annually to the OEC. It is during these updates that the ALAC can provide greater implementation details with regard to those recommendations that are going to be scheduled for the forthcoming six-month period following the respective OEC update. At that time, the ALAC would be in a better position to flag any significant variations from the original implementation plan and timing. The At-Large Review Implementation Plan sets out the prioritization, expected resource allocation in terms of staff time, web and wiki resources, expected budgetary implications such as additional staff resources, and the steps to implementation. While the majority of implementation activities will use existing At-Large resources, any additional fiscal implications are noted below. The ALAC will utilize the normal annual budgetary comment process to request the required resources. If such resources are not provided, the likely result would be a significant slow down in the speed of the Review Implementation.

      Why is the Board addressing the issue?

      This resolution moves the second review of the At-Large community into the implementation phase. Following the assessment of the Implementation Plan and the feedback from the Board's Organizational Effectiveness Committee, the Board is now in a position to consider the Plan and instruct the ALAC to continue the implementation process as set out in the Plan. This step is an important part of the Organizational Review process of checks and balances, to ensure that the spirit of Board-approved recommendations will be addressed through the implementation plans, while being mindful of budgetary and timing constraints.

      What is the proposal being considered?

      The proposal the Board is considering is the Organizational Effectiveness Committee's recommendation of the adoption of the At-Large Review Implementation Plan, drafted and adopted by the At-Large Review Implementation Working Group, endorsed by the ALAC.

      Which stakeholders or others were consulted?

      Immediately after the Board passed the Resolution on the At-Large Review, the leadership of the At-Large Review Working Group provided updates on the Review and next steps on each of the five RALO monthly teleconferences. The creation of the At-Large Review Implementation Working Group involved careful consideration of members to ensure geographical balance and diversity within each RALO, including among the 232 At-Large Structures and over 100 individual members. During the development of the At-Large Review Implementation Plan, the At-Large Review Implementation WG members updated the ALAC as well as each RALO on a regular basis with the progress that was being made. There were also several discussions on the At-Large Review Implementation during ICANN63 face-to-face sessions. At each step, feedback was discussed by the At-Large Review Implementation WG and incorporated into the final Plan.

      What concerns, or issues were raised by the community?

      During the development of the At-Large Review Implementation Plan, the At-Large community raised the concern over whether the third At-Large Summit (ATLAS III) would take place as tentatively scheduled during ICANN66 in Montreal in October 2019 and identified as a Priority 1 activity and requiring budgetary consideration in advance of the broader organizational budget cycle. In September 2018 the Board confirmed that the ICANN organization still had authority to proceed with the planning and contracting.

      What significant materials did the Board review?

      The Board reviewed the At-Large Review Implementation Plan as adopted by the At-Large Review Implementation Working Group and endorsed by the ALAC.

      Are there fiscal impacts or ramifications on ICANN, the Community, and/or the Public (strategic plan, operating plan, or budget)?

      The work to improve the effectiveness of the At-Large organization – by implementing the issues resulting from the Review and the At-Large Review Implementation Overview Proposal, may require additional financial resources that are subject to ICANN's normal budgetary processes. This resolution does not authorize any specific funding for those implementation efforts. The Board understands that some of the Priority 1 work, such as skills development and communication efforts, will require FY20 Additional Budget Requests. The Board also understands that the ongoing and Priority 2 activities are estimated to require the addition of one Full Time Employee equivalent, and there are other anticipated resource needs for items such as communications and data collection.

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

      This action is not expected to have a direct impact on the security, stability or resiliency of the DNS. Still, once the improvements are implemented, future activities of the ALAC and At-Large community, including advice or inputs into the policy development processes, will become more transparent and accountable, which in turn might indirectly contribute to the security, stability or resiliency of the DNS.

      Is public comment required prior to Board action?

      The Draft Report of the independent examiner was posted for public comment. There is no public comment required prior to this Board action. The voice of the ALAC has been reflected throughout the review process – via the At-Large Review Working Party that produced the ALAC Implementation Overview Proposal; the At-Large Review Implementation Working Group that developed the implementation plan; and the ALAC that endorsed the implementation plan.

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

      Given that At-Large represents the best interests of individual Internet end users within ICANN's multistakeholder governance approach, the approval of the At-Large Review Implementation Plan, which will lead to a strengthened At-Large community, will have a direct positive impact to ICANN's mission in its bottom-up policy development process. The public interest is also served through this action which furthers the continued development and support of a diverse and informed multistakeholder community.

    4. FY20 IANA Operating Plan and Budget

      Whereas, the draft FY20 IANA Operating Plan and Budget (OP&B) was posted for public comment in accordance with the ICANN Bylaws on 28 September 2018.

      Whereas, comments received through the public comment process were reviewed and responded to and provided to the BFC members for review and comment.

      Whereas, all public comments have been taken into consideration, and where appropriate and feasible, have been incorporated into a final FY20 IANA OP&B.

      Whereas, the Public Technical Identifier's Board adopted a Final FY20 PTI OP&B on 20 December 2018, which is a required input for the ICANN Board's consideration of the broader IANA OP&B. Per the ICANN Bylaws, once the IANA OP&B is adopted by the ICANN Board, it is then posted on ICANN's website and the Empowered Community has an opportunity to consider the IANA OP&B for rejection.

      Whereas, the public comments received, as well as other solicited community feedback were taken into account to determine required revisions to the draft IANA FY20 Operating Plan and Budget.

      Resolved (2019.01.27.08), the Board adopts the FY20 IANA Operating Plan and Budget, including the FY20 IANA Caretaker Budget.

      Rationale for Resolution 2019.01.27.08

      In accordance with Section 22.4 of the ICANN Bylaws, the Board is to adopt an annual budget for the operation of the IANA functions and publish that budget on the ICANN website. On 28 September 2018 drafts of the FY20 PTI O&B and the FY20 IANA OP&B were posted for public comment. The PTI Board approved the PTI Budget on 20 December 2018, and the PTI Budget was received as input into the FY20 IANA Budget.

      The published draft FY20 PTI OP&B and the draft FY20 IANA OP&B were based on numerous discussions with members of ICANN org and the ICANN Community, including extensive consultations with ICANN Supporting Organizations, Advisory Committees, and other stakeholder groups throughout the prior several months.

      All comments received in all manners were considered in developing the FY20 IANA OP&B. Where feasible and appropriate these inputs have been incorporated into the final FY20 IANA OP&B proposed for adoption.

      The FY20 IANA OP&B will have a positive impact on ICANN in that it provides a proper framework by which the IANA services will be performed, which also provides the basis for the organization to be held accountable in a transparent manner.

      This decision is in the public interest and within ICANN's mission, as it is fully consistent with ICANN's strategic and operational plans, and the results of which in fact allow ICANN to satisfy its mission.

      This decision will have a fiscal impact on ICANN and the Community as is intended. This should have a positive impact on the security, stability and resiliency of the domain name system (DNS) with respect to any funding that is dedicated to those aspects of the DNS.

      This is an Organizational Administrative Function that has already been subject to public comment as noted above. ICANN's Empowered Community now has an opportunity to consider if it will exercise its rejection power over this OB&P.

    5. October 2021 ICANN Meeting Venue Contracting

      Whereas, ICANN intends to hold its last Public Meeting of 2021 in the North America region.

      Whereas, ICANN organization has completed a thorough review of the available venues in the North America region and finds the one in Seattle, Washington to be the most suitable.

      Resolved (2019.01.27.09), the Board authorizes the President and CEO, or his designee(s), to engage in and facilitate all necessary contracting and disbursements for the host venue for the October 2021 ICANN Public Meeting in Seattle, Washington, in an amount not to exceed [REDACTED-FOR NEGOTIATION PURPOSES].

      Resolved (2019.01.27.10), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article III, section 5.2 of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

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

      Rationale for Resolutions 2019.01.27.09 – 2019.01.27.11

      As part of ICANN's Public Meeting strategy, ICANN seeks to host a meeting in a different geographic region (as defined in the ICANN Bylaws) three times a year. ICANN72 is scheduled for 23-28 October 2021. Following a search and evaluation of available venues, the organization identified Seattle, Washington as a suitable location for the ICANN Public Meeting.

      The organization performed a thorough analysis of the available locations and prepared a paper to identify those that met the Meeting Location Selection Criteria (see http://meetings.icann.org/location-selection-criteria). Based on the proposals and analysis, ICANN has identified Seattle, Washington as the location for ICANN72. Selection of this North America location adheres to the geographic rotation guidelines established by the Meeting Strategy Working Group.

      The Board reviewed the organization's briefing for hosting the meeting in Seattle, Washington and the determination that the proposal met the significant factors of the Meeting Location Selection Criteria, as well as the related costs for the facilities selected, for the October 2021 ICANN Public Meeting. ICANN conducts Public Meetings in support of its mission to ensure the stable and secure operation of the Internet's unique identifier systems, and acts in the public interest by providing free and open access to anyone wishing to participate, either in person or remotely, in open, transparent and bottom-up, multistakeholder policy development processes.

      There will be a financial impact on ICANN in hosting the meeting and providing travel support as necessary, as well as on the community in incurring costs to travel to the meeting. But such impact would be faced regardless of the location and venue of the meeting. This action will have no impact on the security or the stability of the DNS.

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

    6. Contract Renewal and Disbursement for ERP Initiative (Oracle Cloud)

      Whereas, ICANN has an established a need to renew contracts for ERP solution, Oracle Cloud.

      Whereas, the Board Finance Committee has reviewed the financial implications of contract renewal with Oracle Cloud for ICANN's ERP solution and has considered alternatives.

      Whereas, both the organization and the Board Finance Committee have recommended that the Board authorize the President and CEO, or his designee(s), to take all actions necessary to execute the contracts with Oracle Cloud for ICANN's ERP solution and make all necessary disbursements pursuant to those contracts.

      Resolved (2019.01.27.12), the Board authorizes the President and CEO, or his designee(s), the take all necessary actions to renew the contracts with Oracle Cloud for ICANN's ERP solution and make all necessary disbursements pursuant to those contracts.

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

      Rationale for Resolutions 2019.01.27.12 – 2019.01.27.13

      ICANN has successfully utilized Oracle Cloud ERP since implementation Go Live in December 2016. Over the past years, ICANN organization has gradually increased the ERP systems and transactional processing knowledge and is in a position to make incremental efficiency improvements to maximize original investment. The Oracle Cloud ERP replaced a then aging Finance, Human Resources and Procurement legacy systems. This solution provided ICANN org with an integrated ERP solution under a single system of record improving systems capacity, global reporting and analysis capability, leading to improved productivity and cross-functional efficiencies, and enhance internal controls.

      Current Contract

      ICANN's current contract with Oracle Cloud ERP was for a three-year period. This contract expired in December 2018. Oracle Cloud has provided ICANN with a one-month contract extension. Annual cost is [REDACTED – FOR NEGOTIATION PURPOSES].

      New Contract

      After thorough analysis, negotiations, and an adjustment to the number of licenses with the supplier, the organization has two options available: (i) three-year contract at [REDACTED – FOR NEGOTIATION PURPOSES] annually with three-year total cost of [REDACTED – FOR NEGOTIATION PURPOSES], (ii) five-year contract at [REDACTED – FOR NEGOTIATION PURPOSES] annually with five-year total cost of [REDACTED – FOR NEGOTIATION PURPOSES].

      After careful analysis of options submitted by the organization, the five-year contract option is considered a viable, cost-effective solution. This solution has lower total cost, lock-in pricing for protection against increases for five years, and flexibility for the organization to perform another overall ERP systems analysis in three years (2021-2022) to determine if the solution set is best for ICANN.

      The Board reviewed the organization's and the Board Finance Committee's recommendations for contracting and disbursement authority for Oracle Cloud ERP contract renewal.

      Taking this Board action fits squarely within ICANN's mission and the public interest in that it ensures that payments of large amounts for one invoice to one entity are reviewed and evaluated by the Board if they exceed a certain amount of delegated authority through ICANN's Contracting and Disbursement Policy. This ensures that the Board is overseeing large disbursements and acting as proper stewards of the funding ICANN receives from the public.

      There will be a financial impact on ICANN to renew Oracle Cloud ERP contract. This impact is currently included in the FY20 Operating Plan and Budget that is pending Board approval. This action will not have a direct impact on the security, stability and resiliency of the domain name system.

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

    7. Reaffirming the Temporary Specification for gTLD Registration Data

      Whereas, on 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data (the "Temporary Specification") to be effective 25 May 2018 for a 90-day period. The Temporary Specification establishes temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in light of the European Union's General Data Protection Regulation (GDPR).

      Whereas, on 21 August 2018, the Board reaffirmed the adoption of the Temporary Specification to be effective for an additional 90-day period beginning on 23 August 2018.

      Whereas, on 6 November 2018, the Board reaffirmed the adoption of the Temporary Specification to be effective for an additional 90-day period beginning on 21 November 2018.

      Whereas, the Board adopted the Temporary Specification pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement for adopting temporary policies. This procedure requires that "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy".

      Resolved (2019.01.27.14), the Board reaffirms the Temporary Specification for gTLD Registration Data pursuant to the procedures in the Registry Agreement and Registrar Accreditation Agreement concerning the establishment of temporary policies. In reaffirming this Temporary Specification, the Board has determined that:

      1. The modifications in the Temporary Specification to existing requirements concerning the processing of personal data in registration data continue to be justified and immediate temporary establishment of the Temporary Specification continues to be necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      2. The Temporary Specification is as narrowly tailored as feasible to achieve the objective to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet.
      3. The Temporary Specification will be effective for an additional 90-day period beginning 19 February 2019.

      Resolved (2019.01.27.14), the Board reaffirms the Advisory Statement Concerning Adoption of the Temporary Specification for gTLD Registration Data, which sets forth its detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders.

      Rationale for Resolutions 2019.01.27.14 – 2019.01.27.15

      The European Union's General Data Protection Regulation (GDPR) went into effect on 25 May 2018. The GDPR is a set of rules adopted by the European Parliament, the European Council and the European Commission that impose new obligations on all companies and organizations that collect and maintain any "personal data" of residents of the European Union, as defined under EU data protection law. The GDPR impacts how personal data is collected, displayed and processed among participants in the gTLD domain name ecosystem (including registries and registrars) pursuant to ICANN contracts and policies.

      On 17 May 2018, the Board adopted the Temporary Specification for gTLD Registration Data ("Temporary Specification") to establish temporary requirements to allow ICANN and gTLD registry operators and registrars to continue to comply with existing ICANN contractual requirements and community-developed policies concerning gTLD registration data (including WHOIS) in relation to the GDPR. The Temporary Specification, which became effective on 25 May 2018, was adopted utilizing the procedure for temporary policies established in the Registry Agreement and the Registrar Accreditation Agreement.

      On 21 August 2018, the Board reaffirmed the Temporary Specification for an additional 90-day period beginning 23 August 2018. On 6 November 2018, the Board again reaffirmed the adoption of the Temporary Specification to be effective for a subsequent 90-day period beginning on 21 November 2018.

      As required by the procedure in the Registrar Accreditation Agreement and Registry Agreements for adopting a temporary policy or specification, "[i]f the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy."

      Today, the Board is taking action to reconfirm the Temporary Specification for an additional 90 days as the temporary requirements continue to be justified in order to maintain the stability or security of registry services, registrar services or the DNS. When adopting the Temporary Specification, the Board provided an Advisory Statement to provide a detailed explanation of its reasons for adopting the Temporary Specification and why the Board believes such Temporary Specification should receive the consensus support of Internet stakeholders. The Board reaffirms the Advisory Statement, which is incorporated by reference into the rationale to the Board's resolutions.

      As required when a temporary policy or specification is adopted, the Board took action to implement the consensus policy development process and consulted with the GNSO Council on potential paths forward for considering the development of a consensus policy on the issues within the Temporary Specification. The consensus policy development process must be concluded in a one-year time period. The Board takes note that the GNSO Council launched an Expedited Policy Development Process on the Temporary Specification, and the Working Group is continuing with its deliberations to develop proposed policy recommendations. On 21 November 2018 the Working Group published for public comment the Initial Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data. The Working Group defined a schedule to produce a final report in February 2019 and for the report to be provided to the Board for consideration prior to the expiration of the 1-year period provided for the Temporary Specification. The Board will continue to engage with the GNSO Council on this matter and reconfirms its commitment to provide the necessary support to the work of the Expedited Policy Development Process to meet the deadline (see 7 August 2018 letter from Cherine Chalaby to GNSO Council Chair: https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf).

      The Board's action to reaffirm the Temporary Specification is consistent with ICANN's mission "[…] to ensure the stable and secure operation of the Internet's unique identifier systems […]". As one of ICANN's primary roles is to be responsible for the administration of the topmost levels of the Internet's identifiers, facilitating the ability to identify the holders of those identifiers is a core function of ICANN. The Board's action today will help serve the public interest and further the requirement in ICANN's Bylaws to "assess the effectiveness of the then current gTLD registry directory service and whether its implementation meets the legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data." [Bylaws Sec. 4.6(e)(ii)]

      Also, this action is expected to have an immediate impact on the continued security, stability or resiliency of the DNS, as it will assist in continuing to maintain WHOIS to the greatest extent possible while the community works to develop a consensus policy. Reaffirming the Temporary Specification is not expected to have a fiscal impact on ICANN organization beyond what was previously identified in the Board's rationale for resolutions 2018.05.17.01 – 2018.05.17.09. If the resource needs are greater than the amounts currently budgeted to perform work on WHOIS- and GDPR-related issues, the President and CEO will bring any additional resource needs to the Board Finance Committee for consideration, in line with existing fund request practices.

      This is an Organizational Administrative Function of the Board for which public comment is not required, however ICANN's approach to addressing compliance with ICANN policies and agreements concerning gTLD registration data in relation to the GDPR has been the subject of comments from the community over the past year (https://www.icann.org/dataprotectionprivacy).

  2. Main Agenda:

    1. Delegation of the موريتانيا. country-code top-level domain representing Mauritania in Arabic Script to Université de Nouakchott Al Aasriya

      Resolved (2019.01.27.16), as part of the exercise of its responsibilities under the IANA Naming Function Contract with ICANN, PTI has reviewed and evaluated the request to delegate the موريتانيا. country-code top-level domain to Université de Nouakchott Al Aasriya. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Rationale for Resolution 2019.01.27.16

      Why the Board is addressing the issue now?

      In accordance with the IANA Naming Function Contract, PTI has evaluated a request for ccTLD delegation 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 create the موريتانيا. country-code top-level domain in Arabic script and assign the role of manager to Université de Nouakchott Al Aasriya.

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, PTI consulted with the applicant and other 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.

    2. Delegation of the .SS (South Sudan) country-code top-level domain to the National Communication Authority (NCA)

      Resolved (2019.01.27.17), as part of the exercise of its responsibilities under the IANA Naming Function Contract with ICANN, PTI has reviewed and evaluated the request to delegate the .SS (South Sudan) country-code top-level domain to National Communication Authority (NCA). The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Rationale for Resolution 2019.01.27.17

      Why the Board is addressing the issue now?

      In accordance with the IANA Naming Function Contract, PTI has evaluated a request for ccTLD delegation 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 create the .SS country-code top-level domain and assign the role of manager to National Communication Authority (NCA).

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, PTI consulted with the applicant and other 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 significantly interested parties.

      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.

    3. GAC Advice: Barcelona Communiqué (October 2018)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN63 meeting in Barcelona, Spain and issued advice to the ICANN Board in a communiqué on 25 October 2018 ("Barcelona Communiqué").

      Whereas, the Barcelona Communiqué was the subject of an exchange between the Board and the GAC on 28 November 2018.

      Whereas, in a 20 December 2018 letter, the GAC provided additional clarification of language contained in the Barcelona Communiqué Annex titled Follow-up to Original Joint Statement by ALAC and GAC (Abu Dhabi, 2 November 2017).

      Whereas, in a 21 December 2018 letter, the GNSO Council provided its feedback to the Board concerning advice in the Barcelona Communiqué relevant to generic top-level domains to inform the Board and the community of gTLD policy activities that may relate to advice provided by the GAC.

      Whereas, the ICANN organization published a memorandum and historical briefing paper providing clarification regarding the development and evolution of ICANN organization's procedure for the release of two-character labels at the second level and the standard framework of measures for avoiding confusion with corresponding country codes.

      Whereas, the Board developed a scorecard to respond to the GAC's advice in the Barcelona Communiqué, taking into account the dialogue between the Board and the GAC, the clarification letter provided by the GAC Chair, the information provided by the GNSO Council, and the memorandum and briefing paper released by the ICANN org.

      Whereas, the Board has considered the previously deferred GAC advice regarding two-character country codes at the second level from the Panama Communiqué, and has included a response in the current scorecard "GAC Advice – Barcelona Communiqué: Actions and Updates (25 January 2019)".

      Resolved (2019.01.27.18), the Board adopts the scorecard titled "GAC Advice – Barcelona Communiqué: Actions and Updates (25 January 2019)" in response to items of GAC advice in the Barcelona Communiqué and the Panama Communiqué.

      Rationale for Resolution 2019.01.27.18

      Article 12, Section 12.2(a)(ix) of the ICANN Bylaws permits the GAC to "put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies." In its Barcelona Communiqué (25 October 2018), the GAC issued advice to the Board on: two-character country codes at the second level and protection of names and acronyms of Intergovernmental Organizations (IGOs) in gTLDs. The GAC also provided a follow-up to previous advice GDPR and WHOIS, the Dot Amazon applications, protection of the Red Cross and Red Crescent designations and identifiers, and a follow-up to the joint statement by ALAC and GAC (Abu Dhabi, 2 November 2017). The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. Any GAC advice approved by a full consensus of the GAC (as defined in the Bylaws) may only be rejected by a vote of no less than 60% of the Board, and the GAC and the Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution.

      The Board is taking action today on all items in the Barcelona Communiqué, including the items related to two-character country codes at the second level as well as protections of IGOs. The Board is also taking action on the items regarding two-character country codes at the second level from the Panama Communiqué, consideration of which had been previously deferred.

      The Board will continue to defer consideration of five items from the San Juan Communiqué, including: four advice items related to GDPR and WHOIS and one advice item related to IGO reserved acronyms, pending further discussion with the GAC. The Board will consider if further action is needed following these discussions.

      The Board's actions are described in the scorecard dated 25 January 2019.

      In adopting its response to the GAC advice in the Barcelona Communiqué, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      The adoption of the GAC advice as provided in the scorecard will have a positive impact on the community because it will assist with resolving the advice from the GAC concerning gTLDs and other matters. There are no foreseen fiscal impacts associated with the adoption of this resolution. Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS. This is an Organizational Administrative function that does not require public comment.

    4. Adoption of GNSO Consensus Policy relating to Certain Red Cross & Red Crescent Names at the Second Level of the Domain Name System

      Whereas, in March 2017 the Generic Names Supporting Organization ("GNSO") and the Governmental Advisory Committee ("GAC") engaged in a good faith, facilitated dialogue in an attempt to resolve outstanding differences between the GNSO's original Policy Development Process ("PDP") consensus recommendations and the GAC's advice concerning certain Red Cross and Red Crescent names.

      Whereas, in the course of that facilitated dialogue the GAC and the GNSO noted certain specific matters, namely:

      1. The public policy considerations associated with protecting identifiers associated with the international Red Cross movement ("Movement") in the domain name system;
      2. The GAC's rationale for seeking permanent protection for the terms most closely associated with the Movement and its respective components is grounded in the protections of the designations "Red Cross", "Red Crescent", "Red Lion and Sun", and "Red Crystal" under international treaty law and under multiple national laws;
      3. The list of names of the Red Cross and Red Crescent National Societies is a finite, limited list of specific names of the National Societies recognized within the Movement (http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf );
      4. There are no other legitimate uses for these terms; and
      5. The GAC had provided clarification following the completion of the GNSO PDP, via its March 2014 Singapore Communiqué, on the finite scope of the specific list of Movement names for which permanent protections were being requested (https://gacweb.icann.org/download/attachments/28278854/Final%20Communique%20%20Singapore%202014.pdf?version=1&modificationDate=1397225538000&api=v2).

      Whereas, following the GAC-GNSO discussion, the ICANN Board had requested that the GNSO Council consider initiating the GNSO's process for amending previous GNSO policy recommendations concerning the full names of the Red Cross National Societies and the International Committee of the Red Cross and International Federation of Red Cross and Red Crescent Societies, and a defined, limited set of variations of these names, in the six official languages of the United Nations (https://www.icann.org/resources/board-material/resolutions-2017-03-16-en#2.e.i).

      Whereas, in May 2017 the GNSO Council resolved to reconvene the original PDP Working Group to consider the Board's request (https://gnso.icann.org/en/council/resolutions#20170503-071).

      Whereas, in August 2018 the reconvened PDP Working Group submitted six recommendations that received the Full Consensus of the Working Group to the GNSO Council (https://gnso.icann.org/en/issues/igo-ingo/red-cross-protection-policy-amend-process-final-06aug18-en.pdf), including a defined, limited set of variations of the Red Cross and Red Crescent names to be reserved under the proposed Consensus Policy (https://gnso.icann.org/en/issues/igo-ingo/red-cross-identifiers-proposed-reservation-06aug18-en.pdf).

      Whereas, in September 2018 the GNSO Council voted unanimously to approve all the PDP consensus recommendations (https://gnso.icann.org/en/council/resolutions#20180927-3) and in October 2018 further approved the submission of a Recommendations Report to the ICANN Board (https://gnso.icann.org/en/council/resolutions#20181024-1).

      Whereas, as required by the ICANN Bylaws, a public comment period was opened in November 2018 to allow the public a reasonable opportunity to provide input on the proposed Consensus Policy prior to Board action as well as for the GAC to provide timely advice on any public policy concerns.

      Whereas, the Board has considered the GNSO's recommendations and all other relevant materials relating to this matter.

      Resolved (2019.01.27.19), the Board hereby adopts the final recommendations of the reconvened International Governmental Organizations (IGO) & International Non-Governmental Organizations (INGO) PDP Working Group, as passed by a unanimous vote of the GNSO Council on 27 September 2018.

      Resolved (2019.01.27.20), the Board directs the President and CEO, or his authorized designee, to develop and execute an implementation plan, including costs and timelines, for the adopted recommendations consistent with ICANN Bylaws Annex A and the Implementation Review Team Guidelines & Principles endorsed by the Board on 28 September 2015 (see https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f), and to continue communication with the community on such work.

      Rationale for Resolutions 2019.01.27.19 – 2019.01.27.20

      Why is the Board addressing the issue?

      The GNSO conducted a PDP, concluding in November 2013, that considered and developed certain policy recommendations for protecting certain identifiers associated with the Red Cross and Red Crescent movement. Those of the GNSO's recommendations that were consistent with GAC advice on the subject; namely, relating to the specific terms "Red Cross", "Red Crescent", "Red Crystal" and "Red Lion & Sun" were adopted by the Board in April 2014 (http://www.icann.org/en/groups/board/documents/resolutions-30apr14-en.htm#2.a). Following implementation work by ICANN Organization and community volunteers, these four specific terms are now withheld from delegation at the top and second levels of the DNS, in the six official languages of the United Nations, under a Consensus Policy that went into force in January 2018.

      The Board did not approve the remaining GNSO policy recommendations from 2013 that concerned other Red Cross and Red Crescent identifiers, e.g. the full names of all the National Societies of the Red Cross movement and those of the International Red Cross and Red Crescent Movement, the International Committee of the Red Cross, and the International Federation of Red Cross and Red Crescent Societies. The Board did not approve these policy recommendations at that time to allow for further discussions between the Board, GNSO, GAC and community about the inconsistencies between the GNSO policy recommendations and the GAC's advice. Over the next several months, the Board facilitated dialogue among the groups about a possible path forward. Following the conclusion of a facilitated dialogue between the GAC and the GNSO in March 2017, the GNSO Council reconvened the original PDP Working Group to consider possible modifications of its previous recommendations concerning these specific identifiers.

      In September 2018, the GNSO Council unanimously approved the modified policy recommendations presented in the final report of the PDP Working Group. With the GNSO Council's unanimous approval of the modified policy recommendations, the Board is now taking action to adopt the revised consensus policy recommendations in accordance with the process documented under the ICANN Bylaws.

      What is the proposal being addressed?

      The PDP recommendations are that certain specific Red Cross and Red Crescent names as well as a list of agreed, permitted variants of those names be withheld from delegation at the second level of the DNS, in all six official languages of the United Nations. The PDP recommendations include a specific, documented process and criteria for correcting errors found on the list of agreed names and variants, as well as for adding or removing entries from the list. The adopted policy will supplement the existing Consensus Policy on protection at the top and second levels of the terms "Red Cross", "Red Crescent", "Red Crystal" and "Red Lion & Sun" in all six official languages of the United Nations.

      For clarity, the PDP recommendations do not include proposals for protection of the specific acronyms associated with the international Red Cross movement, which remains an issue outstanding from the original 2013 GNSO PDP that resulted in recommendations that are inconsistent with GAC advice regarding these acronyms.

      Which stakeholders or others were consulted?

      The reconvened PDP Working Group performed its work in accordance with the GNSO's PDP Manual and Working Group Guidelines, which include provisions pertaining to broad community representation. Members of the Working Group comprised representatives from various parts of the GNSO and ICANN community, including representatives of the Red Cross. The Working Group's Initial Report was published for public comment in June 2018, following which the group considered all input received in developing its final recommendations, all of which received the Full Consensus of the Working Group. Prior to the GNSO Council's vote on the Final Report, the Working Group chair conducted a meeting with community members who had expressed some concerns about the proposed recommendations. The GNSO Council voted unanimously to approve all the recommendations in September 2018.

      The policy recommendations as approved by the GNSO Council were published for public comment in November 2018 and the GAC notified of the Council's action.

      What concerns or issues were raised by the community?

      Possible concerns about freedom of expression were raised concerning reservation of the Red Cross and Red names at the second level of the DNS, as well as the Working Group's development of criteria and a process for adding new names and variants to the list instead of recommending a fixed list. The community also sought clarity about the mechanism for implementing the proposed policy (i.e. whether ICANN Org's contracts with its contracted parties will need to be amended). The Board understands that the Working Group believes it addressed these concerns in developing its final Consensus Policy recommendations.

      Other community comments supported the proposed policy, citing the public policy need to provide adequate protections for the Red Cross against abuse of its names and recognized variants, as well as the fact that the recommended protections are grounded in international humanitarian law and multiple national laws.

      What significant materials did the Board review?

      The Board reviewed the Working Group's Final Report and the recommended protected list of Red Cross names (https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-protection-policy-amend-process-final-06aug18-en.pdf and https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-identifiers-proposed-reservation-06aug18-en.pdf), the GNSO Council's Recommendations Report (https://gnso.icann.org/en/drafts/reconvened-red-cross-recommendations-14oct18-en.pdf), a summary of the public comments received (https://www.icann.org/en/system/files/files/report-comments-red-cross-names-consensus-policy-04jan19-en.pdf) and the relevant GAC advice on this subject (https://gac.icann.org/).

      What factors did the Board find to be significant?

      The recommendations were developed following the GNSO Policy Development Process as set out in Annex A of the ICANN Bylaws and have received the full consensus of the Working Group as well as the unanimous support of the GNSO Council. As stated in the ICANN Bylaws (Annex A, Sec. 9.a.), "Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN."

      The Bylaws also allow for input from the GAC in relation to public policy concerns that might be raised if a proposed policy is adopted by the Board. In this context, the GAC's October 2018 Barcelona Communique expressed the hope that the Board will adopt the GNSO's recommendations.

      Are there positive or negative community impacts?

      The Board's adoption of these recommendations will resolve the issue, outstanding since 2013, of inconsistencies between the GAC's advice and the GNSO's previous policy on these specific Red Cross and Red Crescent names. This means that the interim protections previously put into place by the Board concerning these names will be replaced by the Consensus Policy when it goes into effect, leading to greater clarity as to the scope of protections for these names for ICANN's Contracted Parties and the community at large.

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

      Aside from any financial or other resource costs that may arise during work on implementation of the adopted policy, no fiscal or ramifications on ICANN, the community or the public are envisaged.

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

      There are no security, stability or resiliency issues relating to the DNS that can be directly attributable to the implementation of the PDP recommendations.

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

      This matter concerns the GNSO's policy process, as defined and described by the ICANN Bylaws and the GNSO's operating procedures. All requirements for public comments as part of these processes have been met.

    5. Board Committee Membership and Leadership Changes

      Whereas, Chris Disspain is a member of the Board and the current Chair of the Board Accountability Mechanisms Committee (BAMC).

      Whereas, León Sanchez is a current member of the Board and member of the BAMC.

      Whereas, to facilitate the smooth transition of leadership of the BAMC, the Board Governance Committee (BGC) recommended that the Board immediately appoint León Sanchez as the Chair of the BAMC and retain Mr. Disspain as a member of the BAMC.

      Whereas, Matthew Shears has expressed interest in becoming a member of the Organizational Effectiveness Committee (OEC) and the BGC recommended that the Board immediately appoint Mr. Shears as a member of the OEC.

      Resolved (2019.01.27.21), the Board appoints León Sanchez as the Chair of the BAMC and retains Chris Disspain as a member of the BAMC, effectively immediately.

      Resolved (2019.01.27.22), the Board appoints Matthew Shears as a member of the OEC, effective immediately.

      Rationale for Resolutions 2019.01.27.21 – 2019.01.27.22

      The Board is committed to facilitating a smooth transition in the leadership of its Board Committees as part of the Board's ongoing discussions regarding succession planning. To that end, the Board Accountability Mechanisms Committee (BAMC) has suggested that its current Chair, Chris Disspain, step down as Chair (but remain as a member) and that the Board appoint León Sanchez as Chair of the BAMC. As a member of the BAMC, Mr. Disspain will work with Mr. Sanchez during a transition period.

      As the Board Governance Committee (BGC) is tasked with recommending committee assignments, the BGC has discussed the BAMC's proposal and has recommended that the Board appoint León Sanchez as the new BAMC Chair and retain Mr. Disspain as a member of the BAMC, effectively immediately. The Board agrees with the BGC's recommendation.

      The Board is also committed to facilitating the composition of Board Committees in accordance with the Board Committee and Leadership Selection Procedures. The BGC has considered the interest expressed by Matthew Shears in joining the Organizational Effectiveness Committee and has recommended that the Board approve this appointment. The Board agrees with the BGC's recommendation.

      The action is in the public interest and in furtherance of ICANN's mission as it is important that Board Committees, in performing the duties as assigned by the Board in compliance with ICANN's Bylaws and the Committees' charters, have the appropriate succession plans in place to ensure leadership continuity within the Committees. Moreover, it is equally important that the composition of Board Committees is established pursuant to the Board Committee and Leadership Selection Procedures. This action will have no financial impact on the organization 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.

    6. Consideration of Reconsideration Request 16-11: Travel Reservations SRL, Famous Four Media Limited (and its subsidiary applicant dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, and Radix FZC (and its subsidiary applicant dot Hotel Inc.) (.HOTEL)

      Whereas, Travel Reservations SRL, Fegistry LLC, Minds + Machines Group Limited, and Radix FZC (and its subsidiary applicant dotHotel Inc.) (collectively, the Requestors) submitted standard applications for .HOTEL, which was placed in a contention set with other .HOTEL applications. Another applicant, HOTEL Top-Level-Domain S.a.r.l. (HTLD), submitted a community-based application for .HOTEL.

      Whereas, HTLD participated in Community Priority Evaluation (CPE) and prevailed.

      Whereas, on 9 August 2016, the Board adopted Resolutions 2016.08.09.14 and 2016.08.09.15 (the 2016 Resolutions), which directed ICANN organization to move forward with the processing of the prevailing community application for the .HOTEL gTLD (HTLD's Application) submitted by HTLD.

      Whereas, Requestors submitted Reconsideration Request 16-11 seeking reconsideration of the 2016 Resolutions.

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

      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 the 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 make a telephonic presentation to the BAMC in support of Request 16-11, which the Requestors did on 19 July 2018. The BAMC also invited the Requestors to submit additional written materials in response to the CPE Process Review Reports.

      Whereas, the BAMC has carefully considered the merits of Request 16-11 and all relevant materials and has recommended that Request 16-11 be denied because the Board adopted the 2016 Resolutions based on accurate and complete information. The BAMC also recommended the Board deny Request 16-11 because there is no evidence supporting the Requestors' claim that the Board failed to consider the purported "unfair advantage" HTLD obtained as a result of the Portal Configuration, nor is there evidence that the Board discriminated against the Requestors.

      Whereas, the Board has carefully considered the BAMC's Recommendation on Request 16-11 and all relevant materials related to Request 16-11, 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.01.27.23), the Board adopts the BAMC Recommendation on Request 16-11.

      Rationale for Resolution 2019.01.27.23

      1. Brief Summary and Recommendation

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

        On 16 November 2018, the BAMC evaluated Request 16-11 and all relevant materials and recommended that the Board deny Request 16-11 because the Board adopted the 2016 Resolutions based on accurate and complete information. The BAMC also recommended the Board deny Request 16-11 because there is no evidence supporting the Requestors' claim that the Board failed to consider the purported "unfair advantage" HTLD obtained as a result of the Portal Configuration, nor is there evidence that the Board discriminated against the Requestors.

        On 30 November 2018, the Requestor 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-11, which are set forth in the 2016 Bylaws that were in effect Request 16-11 was filed.2 Nonetheless, the Board has considered the arguments in the Requestors' rebuttal and finds that they do not support reconsideration for the reasons set forth below.

      2. Issue

        The issues are whether the Board's adoption of the 2016 Resolutions occurred: (i) without consideration of material information; or (ii) were taken as a result of its reliance on false or inaccurate material information.

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

      3. Analysis and Rationale

        1. The Board Adopted The 2016 Resolutions After Considering All Material Information And Without Reliance On False Or Inaccurate Material Information.

          The Requestors suggest that reconsideration of the 2016 Resolutions is warranted because ICANN org failed to properly investigate the Portal Configuration and failed to address the alleged actions relating to the Portal Configuration. Specifically, the Requestors assert that ICANN org did not verify the affirmation by Dirk Kirschenowski, the individual whose credentials were used to access confidential information of other authorized users of the New gTLD portal, that he did not and would not provide the information he accessed to HTLD or its personnel. The BAMC concluded, and the Board agrees, that this argument does not support reconsideration because Requestors did not identify any false or misleading information that the Board relied upon, or material information that the Board failed to consider relating to the Portal Configuration in adopting the 2016 Resolutions.

          First, the BAMC determined, and the Board agrees, that ICANN org undertook a careful and thorough analysis of the Portal Configuration and the issues raised by the Requestors regarding the Portal Configuration. The results of the investigation were shared with the ICANN Board, and were carefully considered by the Board in its adoption of the 2016 Resolutions. The BAMC noted that, in its investigation, ICANN org did not uncover any evidence that: (i) the information Mr. Krischenowski may have obtained as a result of the portal issue was used to support HTLD's Application; or (ii) any information obtained by Mr. Krischenowski enabled HTLD's Application to prevail in CPE. Moreover, ICANN's investigation revealed that at the time that Mr. Krischenowski accessed confidential information, he was not directly linked to HTLD's Application as an authorized contact or as a shareholder, officer, or director. Rather, Mr. Krischenowski was a 50% shareholder and managing director of HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin), which was a minority (48.8%) shareholder of HTLD. Mr. Philipp Grabensee, the sole Managing Director of HTLD, informed ICANN org that Mr. Krischenowski was "not an employee" of HTLD, but that Mr. Krischenowski acted as a consultant for HTLD's Application at the time it was submitted in 2012. Mr. Grabenesee further verified that HTLD "only learned about [Mr. Krischenowski's access to the data] on 30 April 2015 in the context of ICANN's investigation." Mr. Grabensee stated that the business consultancy services between HTLD and Mr. Krischenowski were terminated as of 31 December 2015.3

          Second, contrary to the Requestors' assertions, the BAMC determined that ICANN org did verify the affirmation from Mr. Krischenowski that he and his associates did not and would not share the confidential information that they accessed as a result of the Portal Configuration with HTLD. ICANN org also confirmed with HTLD that it did not receive any confidential information from Mr. Krischenowski or his associates obtained from the Portal Configuration. As discussed in the Rationale of the 2016 Resolutions, this information was considered by the Board in adopting the Resolutions.4 As the Board noted Rationale of the 2016 Resolutions, even if Mr. Krischenowski (or his associates) had obtained sensitive business documents belonging to the Requestors, it would not have had any impact on the CPE process for HTLD's Application. The Requestors have not explained how confidential documents belonging to the other applicants for .HOTEL could impact the CPE criteria, which do not consider other entities' confidential information. While Mr. Krischenowski's access occurred prior to the issuance of the CPE Report in June 2014, HTLD did not seek to amend its application during CPE, nor did it submit any documentation that could have been considered by the CPE panel.5 There is no evidence that the CPE Panel had any interaction at all with Mr. Krischenowski during the CPE process, and therefore there is no reason to believe that the CPE Panel ever received the confidential information that Mr. Krischenowski obtained.6

          For these reasons, which are discussed in further detail in the BAMC Recommendation and incorporated herein by reference, the BAMC determined, and the Board agrees, the Requestors did not identify any false or misleading information that the Board relied upon, or material information that the Board failed to consider relating to the Portal Configuration in adopting the 2016 Resolutions. The Board's decision to allow HTLD's Application to proceed was made following a comprehensive investigation, and was well reasoned and consistent with ICANN org's Articles and Bylaws. In particular, in reaching its decision that HTLD's Application should not be excluded, the Board carefully considered the results of ICANN org's forensic review and investigation of the Portal Configuration and the Requestors' claims relating the alleged impact of Portal Configuration on the CPE of HTLD's Application.

        2. The Board Did Not Rely Upon False Or Misleading Information In Accepting The Despegar IRP Panel's Declaration.

          Although Request 16-11 challenges the Board's conduct as it relates to the 2016 Resolutions, the Requestors also appear to challenge the Board's acceptance of the Despegar IRP Panel's Declaration. In particular, the Requestors assert that "the Despegar et al. IRP Panel relied on false and inaccurate material information," such that "[w]hen the ICANN Board accepted the Despegar et al. IRP Declaration, it relied on the same false and inaccurate material information."7

          As an initial matter, the Board agrees with the BAMC's conclusion that the Requestors' claim is time-barred. The Board's resolution regarding the Despegar IRP Panel's Declaration was published on 10 March 2016.8 Request 16-11 was submitted on 25 August 2016, over five months after the Board's acceptance of the Despegar IRP Panel's Declaration, and well past the then 15-day time limit to seek reconsideration of a Board action.9

          1. The Requestors' Claims Regarding the Dot Registry and Corn Lake IRP Panel Declarations Do Not Support their Claims of Discrimination.

            Even had the Requestors timely challenged the Board's resolution regarding the Despegar IRP Panel's Declaration, the Board agrees with the BAMC that the Requestors' claims do not support reconsideration. The Requestors cite to the IRP Panel Declaration issued in Dot Registry, LLC v. ICANN (Dot Registry IRP Panel Declaration) to support their claim that the Despegar IRP Panel Declaration was based "upon the false premise that the [CPE Provider's] determinations are presumptively final and are made independently by the [CPE Provider], without ICANN's active involvement."10 In particular, the Requestors claim that the Dot Registry IRP Panel Declaration demonstrates that "ICANN did have communications with the evaluators that identify the scoring of individual CPEs,"11 such that the Despegar IRP Panel relied upon false information (namely ICANN org's representation in its Response to the 2014 DIDP Request that ICANN org does not engage in communications with individual evaluators who are involved in the scoring of CPEs, which was the subject of Request 14-39), when it found ICANN org to be the prevailing party. As a result, the Requestors suggest that the ICANN Board also relied upon false information when it accepted the Despegar IRP Panel Declaration. The Requestors also argue that they are "situated similarly" to the Dot Registry claimants, and therefore if the Board refuses to grant the Requestors relief when the Board granted the Dot Registry claimants relief, then the Board is discriminating against the Requestors in contradiction to ICANN's Articles and Bylaws. The BAMC concluded, and the Board agrees, that the Dot Registry IRP Declaration and the Board's response to it, however, do not support the Requestors' request for reconsideration for the following reasons.

            First, contrary to the Requestors' assertion, the Dot Registry IRP Panel did not find that ICANN org engaged in communications with CPE evaluators who were involved in the scoring of CPEs. Second, the statements made by one IRP Panel cannot be summarily applied in the context of an entirely separate, unrelated, and different IRP. The Dot Registry IRP concerned .LLC, .INC, and .LLP while the Despegar IRP concerned .HOTEL. Different issues were considered in each IRP, based on different arguments presented by different parties concerning different applications and unrelated factual situations. As such, there is no support for the Requestors' attempt to apply the findings of the Dot Registry IRP Declaration to the Despegar IRP.

            Similarly, the BAMC concluded, and the Board agrees, that the Requestors' citation to the Board's acceptance of the final declaration in Corn Lake, LLC v. ICANN, (Corn Lake IRP Declaration) and decision "to extend its final review procedure to include review of Corn Lake's charity expert determination"12 does not support reconsideration. As was the case with the Dot Registry IRP, the circumstances in the Corn Lake IRP and the Board's subsequent decision concerning .CHARITY involved different facts and distinct considerations specific to the circumstances in Corn Lake's application. As such, the Board's action there does not amount to inconsistent or discriminatory treatment; it is instead an example of the way that the Board must "draw nuanced distinctions between different [gTLD] applications,"13 and is consistent with ICANN's Articles and Bylaws.

          2. The CPE Process Review Confirms that ICANN Org did not have any Undue Influence on the CPE Provider with respect to the CPEs Conducted.

            The BAMC concluded, and the Board agrees, that the Requestors' suggestion that ICANN org exerted undue influence over the CPE Provider's execution of CPE does not warrant reconsideration.14 Indeed, as the BAMC correctly pointed out, this argument has already been addressed by the Board in the 2018 Resolutions.15

            In short, 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 HTLD's Application.16 The Requestors believe that the Scope 1 Report demonstrates that "the CPE Provider was not independent from ICANN. Any influence by ICANN in the CPE was contrary to the policy, and therefore undue."17 The Requestors do not identify what "policy" they are referring to, but regardless, their disagreement with the conclusions of the Scope 1 Report do not support reconsideration. This is because the Requestors do not dispute that, when ICANN org provided input to the CPE Provider, that input did not involve challenging the CPE Provider's conclusions, but rather was to ensure that the CPE Reports were clear and "that the CPE Provider's conclusions"—not ICANN org's conclusions—were "supported by sufficient reasoning."18 The Requestors also cite "phone calls between ICANN and the CPE Provider to discuss 'various issues,'" claiming that those calls "demonstrate that the CPE Provider was not free from external influence from ICANN" org and was therefore not independent.19 Neither of these facts demonstrates that the CPE Provider was "not independent" or that ICANN org exerted undue influence over the CPE Provider. These types of communications instead demonstrate that ICANN org protected the CPE Provider's independence by focusing on ensuring that the CPE Provider's conclusions were clear and well-supported, rather than directing the CPE Provider to reach a particular conclusion. This argument therefore does not support reconsideration. Accordingly, the BAMC concluded, and the Board agrees, that because the Scope 1 Report demonstrates that ICANN org did not exert undue influence on the CPE Provider and CPE process, it disproves the Requestors' claim that "the Despegar et al. IRP Panel was given incomplete and misleading information" which is based solely on the premise of ICANN org's undue influence in the CPE process.20

          3. The Requestors Have Not Demonstrated that ICANN Org was Obligated to Produce Communications Between ICANN Org and the CPE Panel.

            The Board agrees with the BAMC's conclusion that reconsideration is not warranted because, as the Requestors claim, the Despegar IRP Panel did not order ICANN org to produce documents between ICANN org and the CPE Provider. The BAMC noted that that ICANN org was not ordered by the IRP Panel to produce any documents in the Despegar IRP, let alone documents that would reflect communications between ICANN org and the CPE panel. And no policy or procedure required ICANN org to voluntarily produce documents during the Despegar IRP or thereafter.21 In contrast, during the Dot Registry IRP, the Dot Registry IRP Panel ordered ICANN org to produce all documents reflecting "[c]onsideration by ICANN of the work performed by the [CPE Provider] in connection with Dot Registry's application" and "[a]cts done and decisions taken by ICANN with respect to the work performed by the [CPE Provider] in connection with Dot Registry's applications."22 ICANN org's communications with the CPE panels for .INC, .LLC, and .LLP fell within the scope of such requests, and thus were produced. Ultimately, ICANN org acted in accordance with applicable policies and procedures, including ICANN's Bylaws, in both instances.23

          4. The Requestors Have Not Demonstrated that a New CPE of HTLD's Application is Appropriate.

            Without identifying particular CPE criteria, the Requestors ask the Board to "ensure meaningful review of the CPE regarding .hotel, ensuring consistency of approach with its handling of the Dot Registry [IRP Panel Declaration]."24 The BAMC determined, and the Board agrees, that to the extent the Requestors are asserting that the outcome of the CPE analysis of HTLD's Application is inconsistent with other CPE applications, this argument was addressed in Scope 2 of the CPE Process Review. There, "FTI found no evidence that the CPE Provider's evaluation process or reports deviated in any way from the applicable guidelines; nor did FTI observe any instances where the CPE Provider applied the CPE criteria in an inconsistent manner."25 Additionally, for the reasons discussed in above and in detail in the BAMC Recommendation, the Board finds that neither the .HOTEL CPE nor the 2016 Resolutions evidence inconsistent or discriminatory treatment toward the Requestors. For these reasons, this argument does not support reconsideration.

        3. The 2018 Resolutions Are Consistent With ICANN's Mission, Commitments, Core Values and Established ICANN Policy(ies).

          The Requestors' criticisms of the 2018 Resolutions focus on the transparency, methodology, and scope of the CPE Process Review. None support reconsideration. The BAMC found, and the Board agrees, that the BAMC and the Board addressed the Requestors' concerns regarding the 2018 Resolutions in its Recommendation on Request 18-6,26 which the Board adopted on 18 July 2018.27 The rationales set forth by the BAMC, and the Board in its determination of Request 18-6, are incorporated herein by reference.

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

          As an initial matter, Request 16-11 was submitted pursuant to the 11 February 2016 Bylaws, see Discussion supra, which do not call for a rebuttal to the BAMC's recommendation.28 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 11 February 2016 Bylaws Govern Request 16-11.

            The Requestors assert that the Board should consider Request 16-11 under the standards for reconsideration set forth in ICANN org's 18 June 2018 Bylaws, i.e., the version of the Bylaws in effect at the time of the BAMC's recommendation, rather than the 11 February 2016 version which was in effect when Request 16-11 was submitted on 25 August 2016. However, the 18 June 2018 Bylaws did not exist when the Requestors submitted Request 16-11, and the Board did not provide for retroactive treatment when it approved the 18 June 2018 version of the Bylaws; accordingly, the 18 June 2018 Bylaws have no retroactive effect. Indeed, the Reconsideration Request form that the Requestors submitted references the standard for reconsideration under the 11 February 2016 Bylaws, instructing requestors that, for challenges to Board action, "[t]here has to be identification of material information that was in existence [at] the time of the decision and that was not considered by the Board in order to state a reconsideration request." (See Request 16-11, § 8, at Pg. 7.) Therefore, the BAMC correctly considered Request 16-11 under the 11 February 2016 Bylaws, which were in effect when the Requestors submitted Request 16-11.

          2. The Requestors' Challenges to the Bylaws are Untimely.

            The Requestors assert that "the formal requirements of Article 4(2)(q) [of the 18 June 2018 Bylaws] and the circumstances of this case create an unjustified imbalance that prevents Requestors from participating in the reconsideration proceedings in a meaningful way" because the BAMC issued a 33-page recommendation "almost four months" after the Requestors' telephonic presentation concerning Request 16-11, when (under the current Bylaws) rebuttals must be filed within 15 days after the BAMC publishes its recommendations and may not exceed 10 pages. (Rebuttal, at Pg. 1.) As noted above, the operative version of the Bylaws do not provide the Requestors with a right to submit a rebuttal, so reconsideration is not warranted on account of the Requestors' apparent disagreement with the deadlines governing rebuttals under the current (inapplicable) version of the Bylaws.29 Moreover, the Requestors have meaningfully participated in the reconsideration process: the Requestors made a presentation at a telephonic hearing concerning Request 16-11 (Rebuttal, at Pg. 1); and, as noted in the BAMC's Recommendation, the Requestors submitted—and the BAMC considered—seven letters in support of Request 16-11.30 The Requestors have now also submitted a rebuttal in support of Request 16-11, which the Board has considered. Accordingly, the Requestors have not shown that they have been prevented from "meaningful" participation in the reconsideration request process.

          3. The Board Considered Ms. Ohlmer's Actions When it Adopted the 2016 Resolutions.

            The Requestors assert that the "Board ignored the role of [Katrin] Ohlmer" (Rebuttal, at Pg. 3) in the Portal Configuration issue. The Requestors claim that Ms. Ohlmer was CEO of HTLD when she accessed the confidential information of other applicants, and that she had been CEO from the time HTLD submitted HTLD's Application until 23 March 2016. (Request 16-11, § 8, at Pg. 19; see also Rebuttal, at Pg. 3.) The Requestors claim that, because of her role at HTLD, information Ms. Ohlmer accessed "was automatically provided to HTLD." (Rebuttal, at Pg. 4.) The Requestors also assert that "HTLD acknowledged that [Ms. Ohlmer] was (i) principally responsible for representing HTLD, (ii) highly involved in the process of organizing and garnering support for [HTLD's Application], and (iii) responsible for the day-to-day business operations of HTLD."31

            The Board finds that this argument does not support reconsideration as the Board did consider Ms. Olhmer's affiliation with HTLD when it adopted the 2016 Resolutions. Indeed, the Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15 notes that: (1) Ms. Ohlmer was an associate of Mr. Krischenowski; (2) Ms. Ohlmer's wholly-owned company acquired the shares that Mr. Krischenowski's wholly-owned company had held in GmbH Berlin (itself a 48.8% minority shareholder of HTLD); and (3) Ms. Ohlmer (like Mr. Krischenowski) "certified to ICANN [org] that [she] would delete or destroy all information obtained, and affirmed that [she] had not used and would not use the information obtained, or convey it to any third party."32 As the BAMC noted in its Recommendation, Mr. Grabensee affirmed that GmbH Berlin would transfer its ownership interest in HTLD to another company, Afilias plc. Once this transfer occurred, Ms. Ohlmer's company would not have held an ownership interest in HTLD.33

          4. The Requestors' Arguments Concerning HTLD's and Mr. Krischenowski's Assurances and HTLD's Relationship with Mr. Krischenowski Do Not Support Reconsideration.

            The Board finds that the Requestors' arguments that the Board should not have accepted the statements from Messrs. Grabensee or Krischenowski that HTLD did not receive the confidential information from the Portal Configuration does not warrant reconsideration because the Requestors have not provided any arguments or facts that have not already been addressed by the BAMC in its Recommendation.

            Similarly, the Board concludes that the Requestors' arguments that the Board failed to consider timing of HTLD's separation from Mr. Krischenowski in adopting the 2016 Resolutions does not warrant reconsideration. Contrary to the Requestors' argument, it is clear that the Board considered the timing of HTLD's separation from Mr. Krischenowski when it adopted the Resolutions. In the Rationale for the 2016 Resolutions, the Board referenced the same timing in the Rationale for the Resolutions, noting that "the business consultancy services between HTLD and Mr. Krischenowski were terminated as of 31 December 2015" and "Mr. Krischenowski stepped down as a managing director of GmbH Berlin effective 18 March 2016."34 The Requestors disagree with the Board's conclusion that the timing did not support cancelling HTLD's Application, but this disagreement, without more, is not grounds for reconsideration.

          5. The Requestors Do Not Challenge the Application of Specific CPE Criteria to HTLD's Application

            The Requestors claim that the BAMC incorrectly concluded that the Requestors "do not challenge the application of the CPE criteria to HTLD's application or a particular finding by the CPE Provider on any of the CPE criteria." (Rebuttal, at Pg. 9, citing Recommendation, at Pg. 1). However, neither Request 16-11 nor the Rebuttal identifies any of the CPE criteria nor discusses the application of specific CPE criteria to HTLD's Application. (See Request 16-11; Rebuttal.) The Requestors simply reiterate their arguments that the CPE Provider applied (unspecified) CPE criteria "inconsistent[ly] and erroneous[ly]," and that the BAMC should not have considered the CPE Process Review Reports when it made its Recommendation. (Rebuttal, at Pgs. 9-10.) The BAMC addressed these arguments in its Recommendation, and the Board adopts the BAMC's reasoning as if fully set forth herein.

            For these 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.

    7. Consideration of Reconsideration Request 18-9: DotKids Foundation (.KIDS)

      Whereas, in Resolution 2010.03.12.47, as part of the New gTLD Program, the ICANN Board "request[ed] stakeholders to work through their [Supporting Organizations] SOs and [Advisory Committees] ACs, and form a Working Group to develop a sustainable approach to providing support to applicants requiring assistance in applying for and operating new gTLDs."

      Whereas, in response to Resolution 2010.03.12.47, the Joint SO/AC New gTLD Applicant Support Working Group (JAS WG) was formed.

      Whereas, on 13 September 2011, the JAS WG issued its Final Report, setting forth various recommendations regarding financial and non-financial support to be offered to "Support-Approved Candidates" in conjunction with the New gTLD Program.

      Whereas, in Resolution 2011.10.28.21, the Board committed to taking the JAS Final Report seriously, and convened a working group of Board members "to oversee the scoping and implementation of recommendations out of [the JAS Final] Report, as feasible."

      Whereas, in Resolutions 2011.12.08.01 – 2011.12.08.03, the Board approved the implementation plan of the JAS Final Report developed by the Board working group, directed ICANN organization to finalize the implementation plan in accordance with the proposed criteria and process for the launch of the Applicant Support Program (ASP) in January 2012, and approved a fee reduction to US$47,000 Applicant Support candidates that qualify for the established criteria.

      Whereas, the Requestor DotKids Foundation submitted a community-based application for .KIDS, which was placed in a contention set with one other .KIDS application and an application for .KID.

      Whereas, the Requestor applied for, and was awarded, financial assistance in the form of a reduced application fee pursuant to the ASP.

      Whereas, the Requestor participated in Community Priority Evaluation and did not prevail, and an ICANN Auction was scheduled for 10 October 2018.

      Whereas, in August 2018, the Requestor contacted ICANN org to request financial support for engaging in the string contention resolution process, which ICANN org denied as being out of scope for the ASP.

      Whereas, on 21 September 2018, the Requestor submitted Reconsideration Request 18-9, seeking reconsideration of ICANN org's response to its request for financial assistance to participate in the string contention resolution process.

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

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

      Whereas, the BAMC has carefully considered the merits of Request 18-9 and all relevant materials and has recommended that Request 18-9 be denied because ICANN org adhered to established policies and procedures in responding to the Requestor's request for financial assistance for engaging in the string contention resolution process; and ICANN org did not violate its core values established in the Bylaws concerning the global public interest.

      Whereas, on 3 December 2018, the Requestor submitted a rebuttal to the BAMC Recommendation on Request 18-9.

      Whereas, the Board has carefully considered the BAMC's Recommendation on Request 18-9 and all relevant materials related to Request 18-9, 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.01.27.24), the Board adopts the BAMC Recommendation on Request 18-9.

      Rationale for Resolution 2019.01.27.24

      1. Brief Summary and Recommendation

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

        On 16 November 2018, the BAMC evaluated Request 18-9 and all relevant materials and recommended that the Board deny Request 18-9 because ICANN org adhered to established policies and procedures in responding to the Requestor's request for financial assistance for engaging in the string contention resolution process; and ICANN org did not violate its core values established in the Bylaws concerning the global public interest.

        On 3 December 2018, the Requestor submitted a rebuttal to the BAMC's Recommendation (Rebuttal). The Board notes that the Rebuttal was submitted after the time period allotted under Article 4, Section 4.2(q) of the ICANN Bylaws. Nonetheless, the Board has considered the arguments in the Requestor's rebuttal and finds that they do not support reconsideration for the reasons set forth below.

      2. Issue

        The issues are as follows:

        • Whether ICANN org complied with established policies when responding to the Requestor's request for financial support for engaging in the string contention resolution process for the .KID/.KIDS contention set under the ASP; and
        • Whether ICANN org complied with its Core Values established in the Bylaws concerning ICANN org's commitment concerning the global public interest.35

        These issues are considered under the relevant standards for reconsideration requests, which are set forth in the BAMC Recommendation.

      3. Analysis and Rationale

        1. ICANN Org Adhered to Established Policies and Procedures in Responding to the Requestor's Request for Financial Assistance.

          The Requestors suggest that reconsideration is warranted because ICANN org's denial of its request for financial assistance to participate in contention resolution contradicts the JAS Final Report. Specifically, the Requestor claims that ICANN org was under "time pressure" when it considered the JAS Final Report, which caused the ICANN Board to only approve the JAS WG's recommendation for a reduction in the application fee for qualified applicants and, correspondingly, the ICANN Board did "not consider[]" other parts of the recommendations at that time.36 The BAMC determined, and the Board agrees, that the Requestor has not provided any evidence to support its claim that the ICANN Board did not consider the entire JAS Final Report in 2011. As discussed in detail in BAMC Recommendation and incorporated herein by reference, the ICANN Board did thoughtfully and fully consider all of the recommendations set forth in the JAS Final Report. On 28 October 2011, the ICANN Board resolved to "seriously" consider the Final Report and convened a working group of Board members "to oversee the scoping and implementation of the recommendations arising out of [the JAS Final Report], as feasible."37 The Board working group thereafter worked with a subgroup of community members appointed by the JAS WG to develop the Process and Criteria documents that set forth the scope and requirements of the ASP, which the Board then approved in December 2011.38

          The fact that the ICANN Board did not adopt all of the JAS Final Report's recommendations when it approved the implementation plan in accordance with the Process and Criteria documents does not support the Requestor's view that ICANN org did not consider (and reject) the recommendations which were not implemented. As an initial matter, no policy or procedure required ICANN to adopt the recommendations set forth in the JAS Final Report in full. To the contrary, as noted in the JAS Final Report, the recommendations were only "submitted for consideration to the GNSO, ALAC, ICANN Board and ICANN community."39 It remained within the ICANN Board's discretion to determine which recommendations to implement, if any, and the ICANN Board resolved to do so only "as feasible."40

          The Requestor's position also is contradicted by the plain language of the Rationale for Resolutions 2011.12.08.01 – 2011.12.08.03, which specified that that Board had considered and determined not to adopt all of the recommendations set forth in the JAS Final Report: "Note: This process does not follow all JAS recommendations."41 Instead, the Board, in its discretion, found it feasible and resolved to approve financial assistance in the form of a "fee reduction to $47,000" for qualifying Applicant Support candidates.42

          As the BAMC noted, the only JAS recommendations approved by the Board are those set forth in the Process and Criteria documents, which in turn defined the scope and requirements of the ASP. All other JAS WG recommendations were considered and not adopted. Because the ASP, as implemented, does not provide for financial assistance for the contention resolution process, the Board agrees with the BAMC's conclusion that ICANN org did not contravene any established policy or procedure when it denied the Requestor's request for such support.

          Nor does the Requestor identify any policy or procedure (because there is none) obligating ICANN to go back and reconsider, as part of the current New gTLD Program round, the JAS WG's recommendations that were previously not adopted. To the contrary, the requirements of the ASP as set forth in the Process and Criteria documents were intended to be "very clear requirements that are the final requirements of the program for applicant support."43

          The Board further agrees with the BAMC's conclusion that even if the Board were to "address the remainder of the JAS Final Report," as the Requestor asks,44 reconsideration still would be not warranted. The BAMC has reviewed the JAS Final Report and associated relevant materials, including comments made in response to the Request for Public Comment, and has confirmed that financial assistance in the form requested by the Requestor was never recommended by the JAS WG or otherwise. Thus, even if ICANN org were to "address the remainder of the JAS Final Report," as the Requestor asks,45 ICANN org would not find any recommendation in the JAS Final Report that financial support be made available for engaging in the contention resolution process.

        2. ICANN Org Adhered to Its Core Values in Responding to the Requestor's Request for Financial Assistance.

          The Board agrees with the BAMC's finding that ICANN org has not violated its core value to act in the global public interest by denying the Requestor's financial assistance request. The Core Value cited by the Requestor provides:

          Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making to ensure that the bottom-up, multistakeholder policy development process is used to ascertain the global public interest and that those processes are accountable and transparent.46

          ICANN org's implementation of the ASP is the embodiment of this Core Value, not, as the Requestor claims, a contravention of it. The Core Value to "seek[] and support broad, informed participation" via the multistakeholder model is illustrated in the ICANN Board's request, in March 2010, that stakeholders "work through their [Supporting Organizations] SOs and [Advisory Committees] ACs, and form a Working Group to develop a sustainable approach to providing support to applicants requiring assistance in applying for and operating new gTLDs."47 The JAS Final Report, which the ICANN Board fully considered, was developed in response to ICANN's commitment to the multistakeholder model, and exemplifies ICANN's commitment to "ascertain the global public interest" as it concerns the New gTLD Program. In resolving to consider the JAS Final Report, the Board noted that it "takes seriously the assertions of the ICANN community that applicant support will encourage diverse participation in the New gTLD Program and promote ICANN's goal of broadening the scope of the multi-stakeholder model."48

          The BAMC determined, and the Board agrees, that the Requestor appears to urge ICANN org to circumvent the established policy set forth in the requirements governing the ASP in a manner favorable to the Requestor, which undermines, rather than bolsters, the global public interest. ICANN org is committed to diversity, operational stability, and non-discrimination, but it is not responsible for guaranteeing a gTLD for any specific applicant. The Requestor has failed to demonstrate any violation of ICANN's core values.

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

          As an initial matter, the Board notes that the Rebuttal is untimely. The Requestor received the Recommendation on 17 November 2018.49 The Rebuttal was due 15 days later, on 2 December 2018.50 The Requestor submitted the Rebuttal on 3 December 2018, one day after the deadline.51 Nonetheless, the Board has considered the arguments in the Requestor's rebuttal and finds that they do not support reconsideration for the following reasons.

          1. Request 18-9 Seeks Reconsideration of ICANN Org's Denial of the Requestor's Request for Financial Support.

            The Requestor argues in the Rebuttal that is not "directly" seeking "funding support." (Rebuttal at Pg. 1. See also id. at Pg. 3 (Request 18-9 "did not request any particular form of financial assistance.").) However, as the BAMC noted in the Recommendation, on 27 August 2018, the Requestor sent an email to ICANN org stating that it was "looking to request financial support for engaging in the string contention resolution process." (BAMC Recommendation at Pg. 9, citing Exhibit A to Recommendation.) The Requestor identified ICANN org's response to this email "reject[ing] the request" as the action it seeks to have reconsidered.52 Accordingly, the BAMC reasonably understood Request 18-9 to seek reconsideration of ICANN org's denial of the Requestor's request for financial support.

            The Requestor now asserts that Request 18-9 "simply" asks "the ICANN Board to initiate the process to consider the remaining parts of the JAS Final Report." (Rebuttal at Pg. 1.) However, the BAMC already considered this claim. The BAMC concluded that "ICANN org did thoughtfully and fully consider all of the recommendations set forth in the JAS Final Report." (BAMC Recommendation, at Pg. 13.) The Board agrees, and adopts the reasoning set forth in the BAMC Recommendation.

            The Board finds that the Requestor's Rebuttal has not provided any new arguments, or identified any policy or procedure (because there is none) obligating ICANN to reconsider the JAS WG's recommendations that it previously did not adopt.

            The Board notes that the Rebuttal expresses disagreement with the BAMC's conclusion that the Board made it clear that it had determined not to adopt all of the recommendations set forth in the JAS Final Report. The Requestor claims that this "at best leaves the question open" as to whether the Board would give further consideration to the recommendations that it did not follow. (Rebuttal, at Pg. 2) However, nothing in the materials cited the Requestor supports the Requestor's assertion that the Board intended to "leave[] . . . open" the possibility of further consideration of the JAS recommendations that it did not adopt in 2011. (Rebuttal, at Pg. 2.) As the BAMC explained, Resolutions 2011.12.08.01 – 2011.12.08.03 and supporting materials make clear that the Board considered and decided not to adopt any JAS WG recommendations except those set forth in the Process and Criteria documents. Specifically, Resolution 2011.12.08.01 directed ICANN org to "finalize the implementation plan in accordance with the proposed criteria and process for the launch of the Applicant Support Program."53 The Process and Criteria documents neither provide for the additional funding the Requestor seeks nor provide for potential reevaluation of the JAS recommendations that the Board did not adopt in 2011.54 The Board is not persuaded by the Requestor's arguments to the contrary, which are based on opinion. The Requestor has not provided any new facts or evidence to demonstrate that reconsideration is warranted.

          2. The JAS WG Never Recommended Financial Support in the Form Sought by the Requestor.

            For the first time in the Rebuttal, the Requestor argues that, without "some further support (e.g., in terms of fee reduction, adjustment, staggering or otherwise), the Applicant Support program simply does not make sense." (Rebuttal, at Pg. 1.) As a preliminary matter, the Bylaws state that Rebuttals "shall . . . be limited to rebutting or contradicting the issues raised in the" Recommendation, and shall "not offer new evidence" if the Requestor "could have provided" that evidence when it originally submitted the Request.55 As such, this argument does not rebut a specific issue raised in the Recommendation; it should have been raised in the Request, and is therefore not properly raised in the Rebuttal. Moreover, any challenge to the Board Resolutions 2011.12.08.01 – 2011.12.08.03 or the ASP is long since time barred. Nevertheless, the Board has considered the argument and concludes that it does not support reconsideration for the following reasons.

            The Requestor argues that the BAMC incorrectly concluded that none of the JAS WG's recommendations that the Requestor relied on in Request 18-9 "suggest a specific intent to make financial support available to assist in the contention resolution process." (Rebuttal, at Pg. 3.) The Requestor asserts that "[e]ven if direct support for the contention resolution process is not available, the adjustment of other fees could have significant impact on" Support-Approved Candidates, and that the BAMC should not have concluded that "just because direct contribution might not be included[,] . . . other fee adjustments" might have been contemplated. (Id.) The BAMC's conclusion was not as limited as the Requestor suggests; the BAMC concluded that the JAS Final Report did not support financial support of any type for any portion of the contention resolution process. (BAMC Recommendation, at Pgs. 15-16.) Additionally, as the BAMC noted, the JAS Final Report specifically stated that, in the case of string contention, the Applicant would have to "'fund[] this additional step'" of the process. (BAMC Recommendation, at Pg. 16, quoting JAS Final Report at 28.) The Requestor does not identify any policy or procedure (nor is there one) requiring ICANN org to modify or add on to the JAS WG's recommendations to provide additional support to the Requestor or similarly situated applicants when the Board has not made such provisions and the report to the Board did not even recommend such support.

            The Board also finds that the Requestor's assertion that the BAMC concluded that "any other further financial support will not help" is inaccurate. (Rebuttal, at Pg. 3.) The BAMC concluded that ICANN org adhered to established policies and procedures when it concluded that additional financial assistance for the Requestor was not available under the ASP. (BAMC Recommendation, at Pgs. 12-16.)

            For the above reasons, none of the Requestor's Rebuttal arguments support reconsideration.

            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 is an Organizational Administrative Function that does not require public comment.

    8. Consideration of Reconsideration Request 16-12: Merck KGaA (.MERCK)

      Whereas, Merck KGaA (Requestor) submitted a community-based application for .MERCK (the Application), which was placed in a contention set with other .MERCK applications.

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

      Whereas, the Requestor submitted Reconsideration Request 16-12, seeking reconsideration of the CPE report of its Application, and ICANN organization's acceptance of that CPE report.

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

      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 Requestor to submit additional materials and to make a presentation to the BAMC in support of Request 16-12.

      Whereas, the Requestor submitted additional materials in support and made a telephonic presentation to the BAMC in support of Request 16-12; the Requestor also submitted a written summary of its telephonic presentation to the BAMC.

      Whereas, the BAMC has carefully considered the merits of Request 16-12 and all relevant materials and has recommended that Request 16-12 be denied because the CPE Provider did not violate any established policies or procedure in its evaluation of Criterion 2 and ICANN org's acceptance of the CPE Provider's Report complied with established policies.

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

      Resolved (2019.01.27.25), the Board adopts the BAMC Recommendation on Request 16-12.

      Rationale for Resolution 2019.01.27.25

      1. Brief Summary and Recommendation

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

        On 14 December 2018, the BAMC evaluated Request 16-12 and all relevant materials and recommended that the Board deny Request 16-12 because the CPE Provider did not violate any established policies or procedure in its evaluation of Criterion 2 and that ICANN organization's acceptance of the CPE Provider's Report complied with established policies.

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

      2. Issue

        The issues are as follows:

        • Whether the CPE Provider adhered to the Guidebook in its application of Criterion 2, Nexus between Proposed String and Community, in the CPE Report;
        • Whether ICANN org complied with applicable policies and procedures when it accepted the CPE Report;
        • Whether ICANN org must disclose documentary information and communications between ICANN org and the CPE Provider relating to the Application; and
        • Whether the Board complied with applicable Commitments, Core Values, and policies when it acknowledged and accepted the findings set forth in the CPE Process Review Reports.

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

      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.57 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.58 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."59 CPE is performed by an independent panel composed of two evaluators who are appointed by the CPE Provider.60 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.61

        2. The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Criterion 2.

          The Requestor claims that the CPE Provider erred in awarding the Requestor's Application zero out of four points for Criterion 2. Criterion 2 evaluates "the relevance of the string to the specific community that it claims to represent."62 It is measured by two sub-criterion: sub-criterion 2-A-Nexus (worth a maximum of three points); and sub-criterion 2-B-Uniqueness (worth a maximum of one point).63

          1. The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Sub-Criterion 2-A-Nexus.

            The Requestor's Application received zero points for sub-criterion 2-A. To obtain three points for sub-criterion 2-A, the applied-for string must "match the name of the community or be a well-known short-form or abbreviation of the community."64 The CPE Provider determined that the Requestor's Application did not satisfy the three point test because the applied-for string does not "match the name of the community as defined in the application, nor is it a well-known short-form or abbreviation of the community."65

            For a score of two, the applied-for string should "closely describe the community or the community members, without over-reaching substantially beyond the community."66 It is not possible to obtain a score of one for this sub-criterion. The CPE Provider also found that the Requestor's Application did not satisfy the two-point test because the applied-for string does not "identify…the community as defined in the application."67

            The CPE Provider found that

            although the string "Merck" matches the name of the community defined in the Application, it also matches the name of another corporate entity known as "Merck" within the US and Canada. This US-based company, Merck & Co., Inc., operates in the pharmaceutical, vaccines, and animal health industry, has 68,000 employees, and had revenue of US$39.5 billion in 2015. It is therefore a substantial entity also known by the name "Merck".68

            The CPE Provider therefore determined that the string is "'over-reaching substantially beyond the community'…it defines because the applied-for string also identifies a substantial entity—Merck in the US and Canada—that is not part of the community defined by the applicant."69

            The BAMC found that, although the Requestor disagrees with the CPE Provider's conclusion, the Requestor has not identified any policy or procedure that the CPE Provider violated in its determination.70 Nor has the Requestor provided any evidence that the CPE Provider violated any established policy or procedure. The BAMC noted that the Requestor does not deny that the U.S.-based entity is connected to the Requestor's community as defined in the Application; to the contrary, the majority of Request 16-12 is devoted to summarizing the decades-old, contentious legal dispute between the Requestor and the U.S.-based Merck & Co., Inc. (a former subsidiary of the Requestor) over which company may use the name "MERCK" outside the United States.71 As such, the BAMC concluded, and the Board agrees, that the Requestor's substantive disagreement with the CPE Provider's conclusion is not grounds for reconsideration.

            Additionally, as reported in the CPE Process Review Scope 2 Report, the CPE Provider acted consistent with the Guidebook in its analysis under sub-criterion 2-A for all the CPEs that were conducted.72

            Consideration of the CPE Provider's treatment of the Merck & Co. Application confirms the consistency of the CPE Provider's analysis of sub-criteria 2-A across the board for all CPEs. In the CPE Report on the community-based application filed by Merck & Co., Inc. for the .MERCK gTLD (Merck & Co. CPE Report), the CPE Provider applied the same reasoning to the Merck & Co. Application as the reasoning included in the Requestor's CPE Report: it found that the Merck & Co., Inc.'s applied-for string (.MERCK) substantially over-reaches beyond the community because the Requestor here is "a substantial entity also known by the name 'Merck'" and is not included in the Merck & Co. Application's community definition in its application for .MERCK.73 There, the CPE Provider considered whether the existence of the Requestor should prevent the Merck & Co. Application from receiving any points on the nexus element.74 For that reason, the CPE Provider awarded the Merck & Co. Application zero points on sub-criterion 2-A, just as the CPE Provider did with respect to the Requestor's Application.75

            With respect to the Requestor's claim that the size of its community is larger than the community associated with Merck & Co., Inc. and therefore "the string clearly identifies the Requestor"76, the BAMC concluded, and the Board agrees, that this assertion does not show that the CPE Provider failed to adhere to any established policy or procedure in concluding that the string .MERCK over-reaches substantially beyond the community definition in the Requestor's Application. Nor has the Requestor shown that the CPE Provider failed to adhere to any policy or procedure in awarding zero points on the nexus element. Rather, as the BAMC noted, the Guidebook specifically instructs that zero points must be awarded if the string substantially over-reaches beyond the community in the application.

            The BAMC determined, and the Board agrees, that the Requestor's suggestion that it should have been awarded more points for sub-criterion 2-A because it "will take all necessary measures, including geo-targeting, to avoid internet access by users in the few territories in which Merck & Co. has trademark rights" does not warrant reconsideration because the Requestor does not point to any policy or procedure indicating that the CPE Provider must (or even should) take geo-targeting considerations into consideration when scoring sub-criterion 2-A. The BAMC notes that no such policy exists under the Guidebook.

            With respect to the Requestor's suggestion that the CPE Provider failed to consider evidence of "unlawful intrusion" into its territories and its "illegal use" of the word Merck by Merck & Co., Inc.,77 the BAMC concluded, and the Board agrees, that the CPE Provider was not required to evaluate the decades-long trademark dispute between the Requestor and Merck & Co., Inc.78,79 Accordingly, the CPE Provider did not violate any established policy or procedure in not taking the ongoing legal disputes into consideration, and this argument does not warrant reconsideration. For the same reason, the Board also agrees with the BAMC's conclusion that ICANN org was not required to provide the CPE Provider with information relating to the legal disputes between the Requestor and Merck & Co., Inc. The Requestor does not and cannot identify any policy or procedure obligating ICANN org to provide such information to the CPE Provider.

          2. The Application of Sub-Criterion 2-A is Consistent with Other CPE Reports.

            The Requestor asserts that the CPE Provider's analysis of sub-criterion 2-A in the CPE Report is inconsistent with its analysis of the same sub-criterion for the applications for .ECO, .RADIO, .SPA, and .ART, claiming that in each of those cases, the "applicant was awarded three points under the nexus requirement although there were other entities using the same name."80 The BAMC concluded, and the Board agrees, that the Requestor provides no support or additional argument concerning this assertion, and further, the argument is misplaced. As discussed in detail in the BAMC Recommendation and incorporated herein by reference, in each of these cases, the CPE Provider determined that the applied-for string did not match the name of the community, but it identified the community without over-reaching substantially beyond the community.81 By contrast, the CPE Provider concluded that .MERCK did match the name of the community, but it also matched the name of another community, that of US-based Merck & Co., Inc.82 Accordingly, the Board agrees with the BAMC's conclusion that reconsideration is not warranted on this basis because the Requestor has not provided any evidence that the CPE Provider contradicted any established policy or procedure.

          3. The CPE Provider Adhered to Applicable Policies and Procedures in its Application of Sub-Criterion 2-B-Uniqueness.

            The BAMC determined, and the Board agrees, that the Requestor has not demonstrated that the CPE Provider violated any policy or procedure in awarding the Requestor's Application zero points for sub-criterion 2-B-Uniqueness. To obtain one point for sub-criterion 2-B, the applied-for string must have no other significant meaning beyond identifying the community described in the application.83 An application that does not qualify for two or three points for sub-criterion 2-A will not qualify for a score of one for sub-criterion 2-B.84 Here, the CPE Provider awarded zero points under sub-criterion 2-B because the applied-for string did not receive a score of two or three on sub-criterion 2-A for the reasons discussed above.85

            The Requestor suggests that the CPE Provider should have awarded the Application one point on the uniqueness element because of the Requestor's longstanding and sole use of its community name MERCK.86 Similar to its arguments in sub-criterion 2-A, the Board agrees with BAMC that Requestor's challenge of the CPE Provider's scoring on sub-criterion is based solely on a substantive disagreement with the CPE Provider's conclusions, which is not grounds for reconsideration. The Requestor has failed to show any policy or procedure violation in connection with the CPE Provider's finding that the Application should receive a score of zero points for sub-criterion 2-B.

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

          The Requestor argues that the CPE Provider "failed to take reasonable care" in drafting the CPE Report, "and misapplied standards and policies developed by ICANN in the [Guidebook], resulting in a denial of due process to the Request[o]r."87 The Board agrees with the BAMC that this argument does not warrant reconsideration. For the reasons discussed above and in further detail in the BAMC Recommendation, the Requestor has not demonstrated any failure by the CPE Provider to follow the established policy and procedures for CPE as set forth in the Guidebook. Rather, the Requestor suggests 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 Panels, 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 extensive community consultation, and adopted by the Board in June 2011.88 The time for challenging the Guidebook has long passed.89

          As the BAMC noted, the Guidebook provides a path for challenging the results of the CPE process through ICANN's accountability mechanisms.90 Indeed, the Requestor has exercised this right by invoking the Reconsideration process with Request 16-12.91 Accordingly, the Board finds that because the CPE Provider's application of Criterion 2 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. The Board further finds that the absence of an appeal mechanism under the Guidebook for the substance of evaluation results does not constitute a due process violation.

        4. The CPE Process Review Supports the Results of the Merck KGaA Application.

          The CPE Process Review Scope 2 Report shows that CPE Provider applied the CPE criteria consistently across all CPEs and that there is no evidence that CPE Provider's evaluation process or reports deviated in any way from the applicable guidelines.92 For this additional reason, the BAMC found, and the Board agrees, that the Requestor's argument that the CPE Provider incorrectly applied Criterion 2 does not support reconsideration.

          The Requestor argues that the CPE Process Review Scope 2 and 3 Reports are excessively narrow and did not reevaluate the CPE Provider's application of the Nexus criteria or assess the propriety or reasonableness of the research undertaken by the CPE Provider.93 For the reasons set forth in the BAMC Recommendation and incorporated herein by reference, the BAMC concluded, and the Board agrees, that the Requestor's claims do not support reconsideration because the Requestor did not demonstrate that any violation of process or procedure has been violated. (BAMC Recommendation, Pgs. 25-28.)

        5. The Requestor's Request for the Disclosure of Documentary Information is Not Grounds for Reconsideration.

          The BAMC determined, and the Board agrees, that the Requestor's request for the disclosure of documentary information between the ICANN org and the CPE provider relating to the Application and CPE Report is not properly made in the context of a reconsideration request, as the Requestor is not asking ICANN org to reconsider Board or staff action or inaction.94 As such, the Board agrees with the BAMC that this is not grounds for reconsideration. To the extent the Requestor wishes to make a request under ICANN's Documentary Information Disclosure Policy (DIDP), the Requestor may do so separately, consistent with the DIDP.95 However, it should be noted that the documentary information that the Requestor seeks was the subject of multiple DIDP Requests and subsequent Requests for Reconsideration, which the Requestor may consider consulting before submitting an additional substantially identical request.96

          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.

    9. AOB

Pubished on 29 January 2019


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

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

3 Letter from Mr. Philipp Grabensee to ICANN (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-23mar16-en.pdf. The Requestors assert that Ms. Ohlmer has also been associated with HTLD. See Request 16-11 § 8, at Pg. 15. The Board considered this information when passing the 2016 Resolutions. See Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15 (https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h. The BAMC concluded that Ms. Ohlmer's prior association with HTLD, which the Requestors acknowledge ended no later than 17 June 2016 (Request 16-11 § 8, at Pg. 15) does not support reconsideration because there is no evidence that any of the confidential information that Ms. Ohlmer (or Mr. Krischenowski) improperly accessed was provided to HTLD or resulted in an unfair advantage to HTLD's Application in CPE. The Board agrees.

4 https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

5 Briefing Materials in Support of Resolutions 2016.08.09.14 – 2016.08.09.15, Pgs. 95-96 (https://www.icann.org/en/system/files/bm/briefing-materials-2-2-redacted-09aug16-en.pdf).

6 Id. at Pg. 95-96.

7 Id., § 8, Pg. 9.

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

9 ICANN Bylaws, 11 February 2016, Art. IV, § 2.5.

10 Request 16-11, § 8, Pg. 12.

11 Id. (emphasis in original).

12 Letter from Crowell and Moring to ICANN Board, dated 28 December 2016, at Pg. 4-5 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-crowell-moring-to-board-redacted-28dec16-en.pdf.

13 Id.

14 Request 16-11, § 8, at Pg. 12-13.

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

16 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).

17 1 February 2018 letter from Petillion to BAMC, at Pg. 3 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-petillion-to-icann-bamc-redacted-01feb18-en.pdf.

18 1 February 2018 letter from Petillion to BAMC, at Pg. 3, citing FTI Scope 1 Report, at Pg. 12 (emphasis added).

19 Id.

20 Id., at Pg. 3.

21 Nothing in ICANN's Bylaws, the DIDP, or other policy or procedure requires ICANN to voluntarily produce in the course of an IRP documents that were properly withheld in response to a DIDP request.

22 Procedural Order No. 3, Dot Registry LLC v. ICANN, ICDR Case No. 01-14-0001-5004 (https://www.icann.org/resources/pages/dot-registry-v-icann-2014-09-25-en.

23 The Requestors were fully aware that communications occurred between ICANN org and the CPE panel, since such communications are expressly contemplated in the CPE Panel Process Document and ICANN disclosed the existence of these communications in the 2014 DIDP Response. See CPE Panel Process Document (https://newgtlds.icann.org/en/applicants/cpe ("The Economist Intelligence Unit works with ICANN when questions arise or when additional process information may be required to evaluate an application.").

24 Request 16-11, § 9, Pg. 20.

25 Scope 2 Report, at Pg. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf.

26 BAMC Recommendation on Request 18-6 (https://www.icann.org/en/system/files/files/reconsideration-18-6-trs-et-al-bamc-recommendation-14jun18-en.pdf.

27 Resolution 2918.07.18.09 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.g.

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

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

30 See https://www.icann.org/resources/pages/reconsideration-16-11-trs-et-al-request-2016-08-25-en (providing links to letters).

31 Id., citing Letter from Grabensee to ICANN org, 18 May 2016, (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-18may16-en.pdf).

32 See Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15, https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

33 Id.

34 Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15, https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

35 See generally, Reconsideration Request 18-9.

36 Reconsideration Request 18-9, § 7 at Pg. 4.

37 28 October 2011 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

38 8 December 2011 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

39 JAS Final Report at I (emphasis added) (http://dakar42.icann.org/meetings/dakar2011/presentation-jas-final-report-13sep11-en.pdf).

40 28 October 2011 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

41 8 December 2011 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1).

42 8 December 2011 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

43 28 October 2011 Board Minutes (emphasis added) (https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

44 Reconsideration Request 18-9, § 7 at Pg. 4.

45 Reconsideration Request 18-9, § 7 at Pg. 4.

46 ICANN Bylaws, 18 June 2018, Art. 1, § 1.2(b)(ii).

47 12 March 2010 Board Resolution (https://www.icann.org/resources/board-material/resolutions-2010-03-12-en.

48 https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

49 Email from Requestor to ICANN, dated 3 December 2018, attached as Attachment __ to the Reference Materials.

50 See ICANN Bylaws, 18 June 2018, Art. 4, § 4.2(q) (setting out deadline for submitting rebuttals).

51 See https://www.icann.org/resources/pages/reconsideration-18-9-dotkids-request-2018-09-21-en.

52 Request 18-9, § 2, at Pg. 1.

53 Resolution 2018.12.08.01 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1 (emphasis added).)

54 See Process and Criteria documents, included in Board Briefing Materials for 8 December 2011 Board Meeting, at pages 81 and 87 of 164 (https://www.icann.org/en/system/files/bm/briefing-materials-3-08dec11-en.pdf.

55 ICANN Bylaws, 18 June 2018, Art. 4, § 4.2(q).

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

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

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

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

60 Id. Module 4, § 4.2.2.

61 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).

62 See Guidebook, Module 4, § 4.2.3 at Pg. 4-13 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf.

63 Id. at Pgs. 4-12-4-13.

64 Id.

65 CPE Report, at Pg. 3.

66 Id. at Pg. 4-12.

67 Id.

68 Id.

69 Id.

70 The Requestor asserts that the BAMC should re-evaluate the Application in the course of making a recommendation on Request 16-12. See Written Submission in support of Oral Presentation to BAMC on 4 September 2018, at Pg. 1 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf). The applicable version of ICANN's Bylaws direct the BAMC to consider only whether the challenged action violates established ICANN policies or procedures and do not authorize the BAMC to perform a de novo review of the Application. See ICANN Bylaws, 11 February 2016, Art. IV, §§ 2.1, 2.2.

71 See Request 16-12, § 8, Pgs. 7-10.

72 CPE Process Review Scope 2 Report, at pgs. 36-37 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf).

73 Id.

74 Merck & Co., Inc. CPE Report, Pg. 4.

75 Id.

76 Request, § 8, Pg. 9.

77 Id.

78 See Request 16-12, § 8, at Pg. 7-10.

79 See, Guidebook, Module 4, § 4.2.3.

80 2017 Presentation Summary at Pg. 3 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-summary-bgc-presentation-31mar17-en.pdf).

81 .ART CPE Report at Pg. 5 (https://newgtlds.icann.org/sites/default/files/tlds/art/art-cpe-1-1675-51302-en.pdf); .SPA CPE Report at Pg. 4 (https://newgtlds.icann.org/sites/default/files/tlds/spa/spa-cpe-1-1309-81322-en.pdf); .ECO CPE Report at Pg. 5-6 (https://newgtlds.icann.org/sites/default/files/tlds/eco/eco-cpe-1-912-59314-en.pdf); .RADIO CPE Report at Pg. 4-5 (https://newgtlds.icann.org/sites/default/files/tlds/radio/radio-cpe-1-1083-39123-en.pdf).

82 CPE Report at Pg. 3-4.

83 Id. at Pg. 4-13.

84 Id. at Pg. 4-14.

85 CPE Report at Pg. 5; see also Guidebook, Module 4, § 4.2.3, Pg. 4-14 ("The phrasing '. . . beyond identifying the community' in the score of 1 for 'uniqueness' implies a requirement that the string does identify the community, i.e. scores 2 or 3 for 'Nexus,' in order to be eligible for a score of 1 for 'Uniqueness.'").

86 Request, § 8, Pg. 11.

87 Request 16-12, § 8, Pg. 6.

88 Id.

89 See https://www.icann.org/resources/board-material/resolutions-2011-06-20-en#1. Under the Bylaws in effect in June 2012, Reconsideration Requests were due no later than thirty days after information regarding the challenged Board action is published 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).

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

91 The Requestor also exercised this right when it filed an IRP proceeding concerning objections that the Requestor and Merck & Co., Inc. filed against each other in the course of their competing applications for the .MERCK gTLD. See https://www.icann.org/en/system/files/files/irp-merck-final-declaration-11dec15-en.pdf.

92 Scope 2 Report, at Pg. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf. The Requestor believes that the Scope 2 Report "has no significance with respect to Merck KGaA's Request for Reconsideration." (12 April 2018 Letter from Bettinger to ICANN, at Pg. 8.) However, the Scope 2 Report's findings are directly relevant to the Requestor's claim that the CPE Provider's determination concerning sub-criterion 2-A-Nexus, was inconsistent with the CPE Provider's determinations under the same sub-criterion for .SPA, .RADIO, .ART, and .ECO.

93 12 April 2018 Letter from Bettinger to ICANN, at Pg. 6 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-supp-submission-12apr18-en.pdf). See also Written Submission in support of Oral Presentation to BAMC on 4 September 2018, at Pg. 7 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf.

94 12 April 2018 Letter from Bettinger to ICANN, at Pg. 10.

95 See https://www.icann.org/resources/pages/didp-2012-02-25-en.

96 See, e.g., DIDP Request 20180115-1 and response thereto (https://www.icann.org/resources/pages/didp-20180115-1-ali-request-2018-02-15-en) (Request for Reconsideration Denied on 18 July 2018 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.c)); DIDP Request 20180110-1 and response thereto (https://www.icann.org/resources/pages/didp-20180110-1-ali-request-2018-02-12-en) (Request for Reconsideration Denied on 18 July 2018 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.b)).

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."