Skip to main content
Resources

Approved Board Resolutions | Open Session of Board workshop, Los Angeles | Regular Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Minutes
    2. Defer Compliance Enforcement of Gaining Registrar Form of Authorization
    3. Recommendations for the Technical Utilization of the Root Zone Label Generation Rules
    4. FY21 IANA Operating Plan and Budget Adoption
    5. Competition, Consumer Trust and Consumer Choice (CCT) Review – Implementation Plan on Six Accepted Recommendations
    6. Branch Manager and Legal Representative of Brussels office
  2. Main Agenda:
    1. GAC Advice: Montréal Communiqué (November 2019)
    2. Delegation of the البحرين. ("albahrain") domain representing Bahrain in Arabic script to the Telecommunications Regulatory Authority (TRA)
    3. Delegation of the .ລາວ ("Lao") domain representing the Lao People's Democratic Republic in Lao script to the Lao National Internet Center (LANIC)
    4. Consideration of BAMC recommendation on Reconsideration Request 19-4

 

  1. Consent Agenda:

    1. Approval of Minutes

      Resolved (2020.01.26.01), the Board approves the minutes of the 3 November 2019 Regular Meeting of the ICANN Board, the 21 November 2019 Special Meeting of the ICANN Board and the 12 December 2019 Special Meeting of the ICANN Board.

    2. Defer Compliance Enforcement of Gaining Registrar Form of Authorization

      Whereas, the Transfer Policy requires that an inter-registrar transfer "may only proceed if confirmation of the transfer is received by the Gaining Registrar from the Transfer Contact" and such authorization "must be made via a valid Standardized Form of Authorization (FOA)".

      Whereas, on 9 October 2019, the Registrar Stakeholder Group (RrSG) wrote to the GNSO Council, reporting that the RrSG had identified an issue in the implementation of the Gaining Registrar FOA Requirement, and asking the Council to request the ICANN Board to refer this issue to the impending Transfer Policy review and instruct ICANN Contractual Compliance not to enforce the Gaining Registrar FOA requirement while such review is ongoing.

      Whereas, on 31 October 2019, the GNSO Council requested that the ICANN Board instruct ICANN org to defer compliance enforcement of the Gaining Registrar FOA requirement until this matter is settled in the GNSO's planned Transfer Policy review.

      Resolved (2020.01.26.02), the Board accepts the GNSO Council request and directs ICANN's President and CEO, or his designee(s), to defer compliance enforcement of the Transfer Policy's Gaining Registrar FOA requirement until the matter is settled in the GNSO Council's planned Transfer Policy review.

      Rationale for Resolution 2020.01.26.02

      Why is the Board addressing the issue?

      The Board is addressing this issue at the request of the GNSO Council. On 31 October 2019, the GNSO Council sent a letter to the ICANN Board asking the Board to instruct ICANN org to defer Contractual Compliance enforcement of the Transfer Policy's Gaining Registrar FOA requirement until the matter is settled in the planned GNSO Transfer Policy review.

      What is the proposal being considered?

      The proposal being considered is a request from the GNSO Council that the ICANN Board direct ICANN org to defer Contractual Compliance enforcement of the requirement in the Transfer Policy regarding the Gaining Registrar FOA.

      The Transfer Policy requires that an inter-registrar transfer "only proceed if confirmation of the transfer is received by the Gaining Registrar from the Transfer Contact." Such authorization "must be made via a valid Standardized Form of Authorization (FOA)." The Temporary Specification, effective 25 May 2018, superseded this Gaining Registrar FOA requirement in certain circumstances, stating that, "[u]ntil such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the related requirements in the Transfer Policy will be superseded…[.]." Section 1.1 of Appendix G to the Temporary Specification provides that when the Gaining Registrar is unable to gain access to then-current Registration Data for the domain name subject to a transfer, the "Gaining Registrar is not REQUIRED to obtain a Form of Authorization from the Transfer Contact."

      However, this superseding provision in Appendix G of the Temporary Specification only applies if the then-current registration data is not accessible in the public WHOIS/Registration Data Directory Service (RDDS) at the time of the transfer request. Where the registration data is displayed in the public WHOIS/RDDS, the Gaining Registrar FOA requirement continues to apply.

      As set forth in greater detail below, the Registrar Stakeholder Group (RrSG) has identified issues with the implementation of this requirement. The GNSO Council cited these issues in submitting this request to the Board.

      The Interim Registration Data Policy for gTLDs (Interim Policy), effective 20 May 2019, requires continued implementation of measures consistent with the Temporary Specification. Additionally, the Phase 1 Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process, at Recommendation #24, is consistent with the Temporary Specification and does not alter the current contractual obligations. Thus, the implementation issues identified by the RrSG will continue to persist when the Registration Data Policy becomes effective.

      In light of these implementation issues, the GNSO Council asked the ICANN Board to refer the Gaining Registrar FOA issue to the anticipated Transfer Policy review and to direct ICANN org to defer compliance enforcement of the Gaining Registrar FOA requirement until this issue is settled in the Transfer Policy review.

      What concerns or issues were raised by the community?

      The RrSG raised concerns about the Gaining Registrar FOA requirement in a 9 October 2019 letter to the GNSO Council. In raising these issues, the RrSG said it was concerned that the Transfer Policy must be implemented in compliance with the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and other applicable privacy laws.

      The RrSG pointed out in its letter that, even where data is present in the registrant email field in the public RDDS output, an email sent to that address may not go directly to the registrant due to the email being obfuscated, redacted, replaced by a web form URL, or use of pseudonymized email addresses. They believe that if a registrar implemented a system to send the Gaining Registrar FOA to any address listed in the public RDDS, there is no guarantee that the email would reach the registrant. As a result, the registrars contend that they are unable to build a reliable automated process to continue processing the large volume of transfers between registrars. According to the registrars, this would ultimately defeat the purpose of the Transfer Policy, which is to enable registrants to have the ability to transfer domain names to other registrars. Additionally, the RrSG asserts that many registrars believe that under the European Union's General Data Protection Regulation (GDPR), the gaining registrar does not have consent to process this information because that would require registrars to send an email to an individual that is not their customer.

      Prior to the adoption of the Temporary Specification, on 1 May 2018, the Contracted Party House (CPH) Tech-Ops committee proposed to ICANN org to remove the Gaining Registrar FOA requirement, stating in a letter that, "After 25 May 2018, gaining registrars will not have the ability to pull the registrant email or a proxy from the public WHOIS output; data will not be available from losing registrar or registry on a consistent basis." They further stated that the current transfer process, which requires both FOAs, was developed before authorization codes were used consistently across registrars. Additionally, the committee said that the Gaining Registrar FOA provides negligible protection in the context of a domain transfer and that registrars seldom rely upon the Gaining Registrar FOA in the context of a transfer dispute.

      Are there positive or negative community impacts?

      In the 9 October 2019 letter, the RrSG stated that they have "observed that the vast majority of ICANN-accredited registrars are no longer sending the Gaining Registrar FOA post Temporary Specification, and there appears to be no evidence of an increase in unauthorized transfers since May 2018." Additionally, ICANN Contractual Compliance has not seen a material increase in complaints regarding unauthorized transfers. The data gathered by ICANN Contractual Compliance shows that 143 unauthorized transfer cases were closed 13 months prior to the adoption of the Temporary Specification (May 2017 – May 2018); and 138 cases were closed 13 months directly following the adoption of the Temporary Specification (June 2018 – June 2019).

      As identified by the CPH Tech-Ops committee, during gTLD transfers when the email address is not present in public RDDS, the AuthInfo code is sufficient to confirm the intent of the registrant to transfer. The Losing Registrar FOA also confirms this intent.

      The Gaining Registrar FOA requirement continues to cause implementation difficulties and compliance issues for many registrars. This deferred compliance period will allow the ICANN community time to consider the Gaining Registrar FOA requirement through the Transfer Policy review. Furthermore, the additional time will allow the affected contracted parties to assess any potential impact on the Transfer Policy and allow ICANN's Contractual Compliance function to focus its resources on requests with greater urgency or impact.

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

      There are no anticipated fiscal impacts on ICANN's resources, the community, and/or the public as a result of this action.

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

      There is no anticipated impact on the security, stability or resiliency of the DNS.

      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 resolution is an organizational administrative function for which no public comment is required.

      Is this action within ICANN's Mission? How does it relate to the global public interest?

      This action is in line with ICANN's mission and is in the public interest as it helps to ensure a consistent and coordinated implementation of policies in gTLDs.

    3. Recommendations for the Technical Utilization of the Root Zone Label Generation Rules

      Whereas, the ICANN Board approved the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels on 4 November 2013, which has been implemented to incrementally develop the Root Zone Label Generation Rules to determine valid top-level domains (TLDs) and their variant labels.

      Whereas, multiple script communities have completed their RZ-LGR proposals, of which sixteen scripts have been integrated into the third version of the RZ-LGR, while many of the remaining scripts are in the process of finalizing their RZ-LGR proposals.

      Whereas, the ICANN Board approved the Recommendations for Managing IDN Variant TLDs on 14 March 2019 which require the use of RZ-LGR to determine valid IDN TLDs and their variant labels, requesting that the ccNSO and GNSO take into account these recommendations for developing their respective policies relevant to IDN variant TLDs while ensuring a consistent solution.

      Whereas, the ICANN Board further requested the ICANN community to form a study group to investigate any issues in technically employing the RZ-LGR to determine valid IDN TLDs and their variant labels;

      Whereas, the ICANN community formed the study group which finalized the Recommendations for the Technical Utilization of the RZ-LGR after taking input from the community, and published these recommendations on 7 October 2019. These recommendations have been reviewed by ICANN org and considered by the ICANN Board.

      Resolved (2020.01.26.03), the Board requests that the ccNSO and GNSO Councils take into account the Recommendations for the Technical Utilization of the RZ-LGR while developing their respective policies to define and manage the IDN variant TLDs for current TLDs as well as for future TLD applications.

      Rationale for Resolutions 2020.01.26.03

      Initial work by the community in 2012 on the issues related to IDN variant TLDs, as part of the Integrated Issues Report (IIR)1, identified that there is no accepted definition for what may constitute a variant relationship between top-level labels. To address this issue ICANN org and the community developed the Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (LGR Procedure)2. This procedure allows to define label generation rules for different scripts to determine valid TLD labels and their variant labels. In 2013, the ICANN Board endorsed this procedure and requested ICANN org and the community to undertake it. Based on process stipulated in the LGR Procedure, to date multiple Generation Panels (GPs) have completed their RZ-LGR proposals, of which sixteen scripts have already been integrated into the third version of the RZ-LGR (RZ-LGR-3). Many of the remaining script communities are also in the process of finalizing their RZ-LGR proposals. Further, the ICANN Board approved the recommendations3 for managing the IDN variant TLDs, which requires the use of RZ-LGR to determine valid IDN TLDs and their variant labels, and requested ccNSO and GNSO to take these into account in their policy development processes.

      With the availability of the RZ-LGR and its anticipated central role in determining valid TLDs and their variant labels, the ICANN Board requested the ICANN community (including Supporting Organizations (SOs), Advisory Committees (ACs) and Internet Architecture Board (IAB)) to study issues in the technical use of the RZ-LGR consistently across all IDN TLDs, including IDN gTLDs and IDN ccTLDs. Accordingly, the RZ-LGR Study Group (SG) was formed from the nominees of SOs, ACs, IAB and additional volunteers from the ICANN community to address the request from the ICANN Board. After its formation, the RZ-LGR SG first worked on the scope of its work and finalized it after feedback received by the community through the first public comment call in August 2018. The SG deliberated the relevant technical details based on this scope and developed a set of recommendations. These recommendations were released in the second public comment by the SG in May 2019. Based on the input from the community, the SG finalized these recommendations and published them on 7 October 2019 for further consideration of the ICANN Board.

      There will be a fiscal impact of these recommendations due to the maintenance of the RZ-LGR based on the LGR Procedure and deployment and maintenance of an LGR Tool to process TLD labels based on the RZ-LGR. The continued fiscal impact for maintaining the RZ-LGR is anticipated to be less significant than the existing financial support being expended for its development. Also, an LGR Tool has already been developed and deployed by ICANN org to support the script-based GPs in developing their RZ-LGR proposals which can be used for processing TLD labels in the future. The actual fiscal impact is also dependent on the recommendations eventually developed by the ccNSO and GNSO Councils through their respective policy processes related to IDN TLDs and their variant labels, and adopted by the ICANN Board.

      The recommendations support ICANN's mission and contribute towards a secure and stable operation of the unique identifier system in multiple ways as they: support a uniform definition of IDN variant TLDs across gTLDs and ccTLDs and for both the existing TLDs and future TLD applications; support a community-driven mechanism to maintain RZ-LGR in line with the LGR Procedure which maintains its stability; and highlight and address any discrepancies between what is allowed through RZ-LGR and what is delegated in the root zone. This is achieved while respecting the community policy development role. The work, supporting the use of RZ-LGR to consistently determine and possibly delegate IDN variant TLDs, also contributes to the public interest by enhancing access to the Internet's Domain Name System (DNS) in different scripts.

    4. FY21 IANA Operating Plan and Budget Adoption

      Whereas, the draft FY21 IANA Operating Plan and Budget (OP&B) was posted for public comment in accordance with the Bylaws on 14 October 2019.

      Whereas, comments received through the public comment process were reviewed and responded to and provided to the Board Finance Committee (BFC) for review and comment.

      Whereas, all public comments have been taken into consideration, and where appropriate and feasible, have been incorporated and a final FY21 IANA OP&B. Per the Bylaws, the IANA OP&B is to be adopted by the Board and then posted on the ICANN website.

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

      Resolved (2020.01.26.04), the Board adopts the FY21 IANA Operating Plan and Budget.

      Rationale for Resolution 2020.01.26.04

      In accordance with Section 22.4 of the ICANN Bylaws, the Board is to adopt an annual IANA budget and publish it on the ICANN website. On 14 October 2019 drafts of the FY21 PTI Operating Plan and Budget (OP&B) and the FY21 IANA OP&B were posted for public comment. The PTI Board approved the FY21 PTI OP&B on 09 January 2020, and the PTI Budget was received as input into the FY21 IANA OP&B.

      The FY21 PTI OP&B and the draft FY21 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 FY21 IANA OP&B. Where feasible and appropriate these inputs have been incorporated into the final FY21 IANA OP&B proposed for adoption.

      The FY21 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 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.

    5. Competition, Consumer Trust and Consumer Choice (CCT) Review – Implementation Plan on Six Accepted Recommendations

      Whereas, ICANN was obligated under the Affirmation of Commitments to "organize a review that will examine the extent to which the introduction or expansion of gTLDs has promoted competition, consumer trust and consumer choice, as well as effectiveness of (a) the application and evaluation process, and (b) safeguards put in place to mitigate issues involved in the introduction or expansion." A community-led review team – the Competition, Consumer Trust and Consumer Choice Review Team (CCT-RT) – was announced on 23 December 2015 to fulfill that mandate.

      Whereas, the CCT-RT submitted a Final Report containing 35 full consensus recommendations to the ICANN Board for consideration on 8 September 2018 ("Final Report").

      Whereas, the ICANN Board took action on each of the 35 recommendations issued within the Final Report as specified within the scorecard titled "Final CCT Recommendations: Board Action (1 March 2019)" ("Scorecard").

      Whereas, the Board resolved to accept CCT recommendations 1, 17, 21, 22, 30, 31, subject to costing and implementation considerations, as specified in the Scorecard, and directed the ICANN President and CEO, or his designee(s), to develop and submit to the Board a plan for the implementation, with the objective of completing and providing the plan to the community for consideration no later than six months after such Board action.

      Whereas, a Plan for Implementation was submitted for public comment on 11 September 2019. Community feedback was also sought on the proposal to include implementation of CCT recommendations in ICANN's operating planning and budgeting process, as appropriate, allowing for appropriate prioritization within the context of all ICANN work. The call for feedback yielded a total of five comments; analysis and ICANN org responses to the input received can be found in the summary produced by ICANN org.

      Resolved (2020.01.26.05), the Board directs the ICANN President and CEO, or his designee(s), to commence implementation of the accepted CCT-RT recommendations as proposed in the Plan for Implementation. Implementation work, where no significant incremental costs and resources are needed, is to begin as soon as possible. Any CCT recommendations addressed in the Plan for Implementation that require significant resources and budget, should be included into operational planning and budgeting processes, allowing for appropriate community consideration and prioritization, as applicable, of planned work.

      Rationale for Resolution 2020.01.26.05

      Why is the Board addressing this issue?

      As detailed in Article 1 of ICANN Bylaws, reviews are important accountability measures that are critical to maintaining a healthy multistakeholder model and to helping ICANN achieve its Mission. Reviews also contribute to ensuring that ICANN serves the public interest. The first Competition, Consumer Trust and Consumer Choice Review (CCT), initiated under the Affirmation of Commitments (AoC), is an important aspect of ICANN's commitment to continuous review and assessment of key areas.

      The Competition, Consumer Trust, and Consumer Choice Review Team (CCT-RT) submitted its Final Report and Recommendations to the ICANN Board of Directors on 8 September 2018.

      On 1 March 2019, the ICANN Board took action on the Final Recommendations produced by the CCT-RT. Per the ICANN Bylaws, the ICANN Board carefully considered how to best address each of the recommendations, and decided on three categories of action: accepted, pending, and passing through to different parts of the community, as documented in a detailed scorecard accompanying the Board resolution.

      Today, the Board is taking action to direct implementation of the accepted recommendations as outlined in the Plan for Implementation.

      What is the proposal being considered?

      ICANN org produced a Plan for Implementation in furtherance of Board resolution 2019.03.01.03 to: 1) accept CCT recommendations 1, 17, 21, 22, 30, 31, subject to costing and implementation considerations; and 2) direct ICANN "to develop and submit to the Board a plan for the implementation of the accepted recommendations.

      The Plan for Implementation sets out the approach for implementation of accepted recommendations. It contains information such as a description of the activities, estimated duration, resource requirements (including funding source), dependencies, and other elements, where available and possible.

      In addition to articulating milestones and steps leading to implementation, the Plan for Implementation informs, as much as possible, on anticipated costs and resources needed to complete implementation. It addresses how the resources allocated to specific recommendations support ICANN in serving its Mission, and to understand the balance of resources and prioritization needed in order to fund the work identified to meet the CCT-RT recommendations.

      The Plan for Implementation was developed by ICANN org subject matter experts leading on topics of the six accepted recommendations.

      Which stakeholders or others were consulted?

      The Plan for Implementation was posted for public comment on 11 September 2019. Community feedback was also sought on the proposal to include implementation of CCT recommendations in the Operating Planning and Budgeting Process, allowing for appropriate prioritization within the broader context of all ICANN work. The call for feedback closed on 31 October and yielded a total of five contributions. As applicable, comments were addressed in the "Analysis" section of the Public Comment Summary Report.

      Prior to releasing the Plan for Implementation, CCT-RT Implementation Shepherds4 were invited to join the Board Caucus Group dedicated to the CCT effort for an overview of the proposed path forward and plans to address the 1 March Board action on CCT Final Recommendations.

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

      As articulated in the Plan for Implementation, implementing these recommendations may in some instances require resources beyond what is allocated in the current budget. Accordingly, the Board resolution calls for those recommendations addressed in the Plan for Implementation that require significant resources and budget to be included into cycles of operational planning and budgeting.

      Are there positive or negative community impacts?

      Adopting the Plan for Implementation will allow ICANN org to begin implementing some of the recommendations developed by the community-led review team as soon as possible. It is anticipated that implementation of specific recommendations will require the community to participate in some consultations, as outlined in the Plan for Implementation. This could potentially affect community workload and resources.

      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.

      Is this action within ICANN's Mission? How does it relate to the global public interest?

      This action is within ICANN's Mission and mandate. It is considered in the public interest as it is a result of a key commitment entered into in 2009 within the Affirmation of Commitments, now embodied in the ICANN Bylaws. Reviews are an important and essential part of how ICANN upholds its commitments. The scope of this review is inherently tied to ICANN's core values of introduction and promotion of competition in the registration of domain names.

      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?

      Public comment was received prior to Board consideration.

    6. Branch Manager and Legal Representative of Brussels office

      Whereas, the Internet Corporation for Assigned Names and Numbers, a non-profit, public benefit corporation, duly incorporated and existing under the laws of the State of California and the United States of America, having its principal place of business at 12025 E. Waterfront Drive, Suite 300, Los Angeles, California USA 90094 ("ICANN"), has established a branch office of a non-profit foreign entity in Belgium, currently residing at 6 Rond Point Schuman, B-1040 Brussels under the name of Internet Corporation for Assigned Names and Numbers.

      Whereas, by resolution 2017.06.24.13 of the ICANN Board, Jean-Jacques Sahel was appointed as the branch manager and legal representative in Belgium, to serve in this capacity until his appointment is withdrawn by resolution of this Board of Directors.

      Whereas, Jean-Jacques Sahel's role as the branch manager and legal representative in Belgium ended in October 2019, upon his resignation from ICANN.

      Whereas, effective 26 January 2020, Christopher Mondini, [PERSONALLY IDENTIFYING CONTACT INFORMATION REDACTED], will assume the duties of the branch manager and legal representative for the ICANN office in Brussels, Belgium.

      Resolved (2020.01.26.06), Jean-Jacques Sahel's authority to act as branch manager and legal representative for ICANN's branch office in Brussels, Belgium shall be withdrawn, effective immediately.

      Resolved (2020.01.26.07), Christopher Mondini shall be the new branch manager and legal representative for ICANN's branch office in Brussels, Belgium, effective 26 January 2020.

      Resolved (2020.01.26.08), Christopher Mondini be delegated full power to carry out the daily management of ICANN's branch office in Brussels, Belgium including, but not limited to, the following specific powers regarding the operations of such branch:

      1. Represent the corporation vis-à-vis all public authorities, whether governmental, regional, provincial, municipal or other, the Enterprise Courts, the Crossroads Bank for Enterprises, the Corporate Counters, the Tax Authorities, including the V.A.T. administration, the Postal Checks service, customs, postal, telephone and telegraph services, and all other public services and authorities.

      2. Sign daily correspondence, receive and sign receipts for registered letters or parcels addressed to the corporation through the post, the customs, the rail-, air- and other transport companies and services.

      3. Take out, sign, transfer or cancel all insurance policies and all contracts for supply of water, gas, power, telephone and other utilities for the branch, and pay invoices, bills and other dues relating thereto.

      4. Sign and accept all quotations, contracts and orders for the purchase or sale of office equipment and other investment goods, services and supplies necessary for the functioning of the branch which do not obligate the corporation to expend more than 500 Euro.

      5. Take or grant leases, including long term leases, on real estate, equipment or other fixed assets and enter into leasing agreements with respect to the same, upon approval from the President and CEO of ICANN or the ICANN Board of Directors.

      6. Claim, collect and receive sums of money, documents or property of any kind and sign receipts with respect thereto.

      7. Affiliate the branch with all professional or business organizations.

      8. Represent the branch in court or arbitration proceedings, as plaintiff or defendant, take all necessary steps with respect to the above proceedings, obtain all judgments, and have them executed.

      9. Draft all documents and sign all papers in order to be able to exercise the powers listed above.

      10. Adopt all necessary measures to implement the resolutions and recommendations of the Board of Directors.

      11. Move the branch to any other location in Belgium upon approval of the ICANN President and CEO or the ICANN Board of Directors.

      Rationale for Resolution 2020.01.26.06 – 2020.01.26.08

      ICANN is committed to continuing its global reach and presence in all time zones throughout the globe. To this end, the ICANN Board passed resolutions establishing a branch office in Belgium and in 2017 appointed Jean-Jacques Sahel as the branch manager and legal representative with associated delegated powers to commit these duties. Mr. Sahel resigned from his employment with ICANN In October 2019. This requires the Board to appoint a new branch manager and legal representative. This resolution, appointing Mr. Mondini as the branch manager and legal representative with delegation of the specific powers required to manage the branch, continues ICANN's effective management of the branch office following the resignation of the former branch manager and legal representative.

      ICANN's commitment to a global reach is consistent with the public interest and with ICANN's mission in that it helps support ICANN's global stakeholder focus.

      There will be a fiscal impact on ICANN only to the extent there are expenses for naming the new branch manager, but such impact can be accounted for in the FY20 budget.

      This resolution is not intended to have any impact on the security, stability and resiliency of the domain name system.

      This is an Organizational Administrative Function not requiring public comment.

  2. Main Agenda:

    1. GAC Advice: Montréal Communiqué (November 2019)

      Whereas, the Governmental Advisory Committee (GAC) met during the ICANN66 meeting in Montréal, Canada and issued a communiqué on 6 November 2019 ("Montréal Communiqué"), which contains four items of consensus advice and three items of follow-up to previous advice. The consensus advice concerns the CCT Review and Subsequent Rounds of New gTLDs, and Domain Name Registration Directory Service and Data Protection. The follow-up to previous advice concerns Protection of the Red Cross and Red Crescent Designations and Identifiers, IGO Protections, and Domain Name Registration Directory Services and Data Protection.

      Whereas, in a 16 December 2019 letter, the ICANN President and CEO provided information on the implementation efforts related to the CCT Review and posed clarifying questions regarding the GAC's advice on the topic to the GAC Chair.

      Whereas, in a 17 December 2019 call, the ICANN Board and GAC discussed the Montréal Communiqué and any clarifying questions from the ICANN Board regarding the GAC's advice.

      Whereas, in a 19 December 2019 letter, the GNSO Council provided its feedback to the Board concerning the follow-up to previous advice contained in the Montréal Communiqué.

      Whereas, in a 6 January 2020 letter, ICANN org provided an update on the EPDP Phase 1 Implementation schedule, as requested by the GAC in its Montréal Communiqué.

      Whereas, in a 22 January 2020 letter, the GAC provided additional clarifications regarding its advice in its Montréal Communiqué.

      Whereas, the Board developed a scorecard to respond to the GAC's advice in the Montréal Communiqué, taking into account previous dialogue between the Board and the GAC on the topics as well as the information provided by the GNSO Council.

      Resolved (2020.01.26.09), the Board adopts the scorecard titled "GAC Advice – Montréal Communiqué: Actions and Updates (26 January 2020)" in response to items of GAC advice in the Montréal Communiqué.

      Rationale for Resolutions 2020.01.26.09

      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 Montréal Communiqué (6 November 2019), the GAC issued consensus advice to the Board on the CCT Review and Subsequent Rounds of New gTLDs, and Domain Name Registration Directory Service and Data Protection. The GAC also issued follow-ups to previous advice on the Protection of the Red Cross and Red Crescent Designations and Identifiers, IGO Protections, and Domain Name Registration Directory Services and Data Protection. 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 Montréal Communiqué.

      The Board's actions are described in the scorecard dated 26 January 2020.

      In adopting its response to the GAC advice in the Montréal 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. Acting on GAC advice is aligned with ICANN's mission and the GAC's role in ICANN's multistakeholder model, and supports the public interest. 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.

    2. Delegation of the البحرين. ("albahrain") domain representing Bahrain in Arabic script to the Telecommunications Regulatory Authority (TRA)

      Resolved (2020.01.26.10), as part of the exercise of its responsibilities under the IANA Naming Function Contract with ICANN, IANA has reviewed and evaluated the request to delegate the البحرين. top-level domain to the Telecommunications Regulatory Authority. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Rationale for Resolution 2020.01.26.10

      Why is the Board addressing the issue now?

      In accordance with the IANA Naming Function Contract, PTI, in the performance of the IANA Naming Function (IANA), 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 the Telecommunications Regulatory Authority.

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, IANA 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?

      IANA 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?

      The Board reviewed the following evaluations:

      [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. Delegation of the .ລາວ ("Lao") domain representing the Lao People's Democratic Republic in Lao script to the Lao National Internet Center (LANIC)

      Resolved (2020.01.26.11), as part of the exercise of its responsibilities under the IANA Naming Function Contract with ICANN, IANA has reviewed and evaluated the request to delegate the .ລາວ top-level domain to the Lao National Internet Center. The documentation demonstrates that the proper procedures were followed in evaluating the request.

      Rationale for Resolutions 2020.01.26.11

      Why is the Board addressing the issue now?

      In accordance with the IANA Naming Function Contract, PTI, in the performance of the IANA Naming Function (IANA), 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 Lao script and assign the role of manager to the Lao National Internet Center.

      Which stakeholders or others were consulted?

      In the course of evaluating a delegation application, IANA 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?

      IANA 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?

      The Board reviewed the following evaluations:

      [REDACTED – SENSITIVE DELEGATION INFORMATION]

      What factors the Board found to be significant?

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

      Are there positive or negative community impacts?

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

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

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

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

      ICANN does not believe this request poses any notable risks to security, stability or resiliency. This is an organizational administrative function not requiring public comment.

    4. Consideration of BAMC recommendation on Reconsideration Request 19-4

      Whereas, Merck KGaA and Merck Registry Holdings, Inc. (Requestors) submitted Reconsideration Request 19-4 seeking reconsideration of ICANN organization's denial of their mutual request for a second postponement of a string contention auction for the .MERCK generic top-level domain (gTLD) (Second Request).

      Whereas, the Requestors claim that ICANN Staff failed to consider material information and violated established ICANN policies favoring voluntary string contention settlement and permitting discretionary waiver of deadlines when it denied the Second Request.

      Whereas, the Requestors further claim that denial of the Second Request violated ICANN's Commitment in its Bylaws to "[m]ake decisions by applying documented policies neutrally and objectively with integrity and fairness."

      Whereas, the Board Accountability Mechanisms Committee (BAMC) previously determined that Request 19-4 is sufficiently stated and sent Request 19-4 to the Ombudsman for 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 carefully considered the merits of Request 19-4 and all relevant materials and recommended that Request 19-4 be denied because ICANN Staff did not fail to consider material information and did not violate ICANN's Commitments, Core Values or established ICANN policy(ies) in its denial of Requestors' Second Request.

      Whereas, the BAMC recommended that the Board ask ICANN organization to seek an update from Requestors and, if the Requestors jointly declare they have made progress since filing Request 19-4 and that they are very close to private resolution, to consider providing some form of discretionary relief to allow the Requestors time to finalize a private resolution.

      Whereas, the Requestors submitted a Rebuttal to the BAMC's Recommendation pursuant to Article 4, Section 4.2(q) of the ICANN Bylaws.

      Whereas, the Rebuttal provided an update on the Requestors' progress toward reaching private resolution of the string contention issue and stated that the Requestors are not likely to resolve their disputes concerning .MERCK in the next month, and requested postponement of the auction until the end of August 2020.

      Resolved (2020.01.26.12), the Board adopts the BAMC Recommendation and thereby denies Reconsideration Request 19-4.

      Resolved (2020.01.26.13), the Board directs the President and CEO, or his designee(s), to seek an additional update from the Requestors on settlement progress. If the Requestors jointly declare they have made progress since filing Request 19-4 and ICANN organization is satisfied that the Requestors are very close to private resolution, the Board asks the President and CEO, or his designee(s), to consider providing the Requestors with some form of discretionary relief to allow them a short amount of time to finalize a private resolution.

      Resolved (2020.01.26.14), if the Requestors do not provide an additional update regarding their settlement progress and/or if ICANN organization is not satisfied that the Requestors are very close to private resolution, the Board directs the President and CEO, or his designee(s), to continue processing the .MERCK applications, including scheduling an auction if ICANN organization deems it appropriate.

      Rationale for Resolutions 2020.01.26.12 – 2020.01.26.14

      1. Brief Summary and Recommendation

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

        On 19 December 2019, the BAMC evaluated Request 19-4 and all relevant materials and recommended that the Board deny Request 19-4 because ICANN Staff did not fail to consider material information and did not violate ICANN's Commitments, Core Values or established ICANN policy(ies) in its denial of Requestors' Second Request.

        On 3 January 2020, the Requestors submitted a Rebuttal to the BAMC Recommendation (Rebuttal) pursuant to Article 4, Section 4.2(q) of ICANN's Bylaws. The Requestors claim that: (1) the BAMC mischaracterized the history of the Requestors' disputes over trademark rights involving the word "Merck"; (2) the Applicant Guidebook's rule prohibiting multiple renewals does not apply to the Requestors; (3) the BAMC improperly penalized the Requestors for not submitting evidence that ICANN Staff failed to consider material information; (4) by denying the Second Request, ICANN Staff discriminated against the Requestors; and (5) although Requestors initially expected that they would be able to resolve the string contention by early 2020, the Requestors now ask ICANN Staff to postpone the auction until the end of August 2020 to allow adequate time for the Requestors to privately resolve the string contention.

        The Board has carefully considered the BAMC's Recommendation, as well as all relevant materials for Request 19-4, and concludes that Request 19-4 is denied. Consistent with the BAMC's Recommendation, the Board will ask ICANN organization to seek an additional update from the Requestors on settlement progress although the Rebuttal suggested that private resolution, even if achieved, would not occur until August of 2020. If the Requestors jointly declare they have made progress since filing Request 19-4 and ICANN organization is satisfied that the Requestors are closer to private resolution than the Rebuttal suggests, then the Board asks ICANN organization to consider providing the Requestors with some form of discretionary relief that could allow them some limited time to finalize a settlement.

      2. Issue

        The issues are as follows:

        • Whether ICANN Staff failed to consider material information when it denied the Requestors' mutual request for a second postponement of the .MERCK contention set auction.

        • Whether ICANN Staff violated established ICANN policies favoring voluntary settlement of string contentions and allowing for discretionary waiver of deadlines when it denied the Requestors' mutual request for a second postponement of the .MERCK contention set auction.

        • Whether ICANN Staff violated ICANN's Commitment to "[m]ake decisions by applying documented policies consistently, neutrally, objectively, and fairly" when it denied the Requestors' mutual request for a second postponement of the .MERCK contention set auction.

      3. Analysis and Rationale

        1. ICANN Staff Did Not Fail to Consider Material Information Before Denying the Second Request

          ICANN Staff considered all material information in denying the Second Request. The Requestors argue that ICANN Staff disregarded the history of multijurisdictional litigation between them concerning the "Merck" trademark, the fact that the Requestors expected to receive judgments in several pending cases "in the coming months," and the fact that the Requestors were "hopeful" that they would be able to resolve their contention over .MERCK "soon" via voluntary agreement.5 And the Requestors suggest that these facts were material to their Second Request.6 The BAMC concluded that: (1) the Requestors have not presented any evidence to support their belief that ICANN Staff failed to consider the history of the Requestors' dispute; (2) the Requestors' lengthy history of dispute is well known to ICANN Staff; (3) ICANN Staff was aware of the Requestors' ongoing efforts at private resolution; and (4) in any event, information regarding the Requestors' dispute or attempts at private resolution was not material to ICANN Staff's decision on the Second Request.7

          In their Rebuttal, the Requestors argue that they were not required to present evidence supporting their belief that ICANN Staff failed to consider the material information, and that it would be impossible to prove such a negative.8 The Board acknowledges that ICANN Staff did not expressly reference Requestors' "legally-complex and politically-sensitive background"9 in its decision on the Second Request; however, the record shows the exact opposite of what the Requestors are asserting, namely that ICANN Staff was well aware of that background. The Requestors must, but have failed to, rebut this evidence. Accordingly, the BAMC concluded and the Board agrees that the Requestors' long and contentious history was well known to ICANN Staff.10

          The Requestors also challenged ICANN Staff's suggestion, in its denial of the Second Request, that two weeks might be enough "time to pursue and complete the self-resolution of the contention set." Requestors assert that "ICANN Staff did not understand the full extent" of Requestors' ongoing efforts at voluntary settlement; otherwise (according to Requestors), ICANN Staff would have realized that two weeks was not enough time for these parties, given their legally complex and sensitive background, to resolve their disputes.11 However, ICANN Staff's denial of the Second Request merely conveyed that the denial did not, in itself, require the parties to stop trying to privately resolve the string contention. The statement merely makes clear that the parties were free to continue negotiations until the deadline for withdrawing from string contention. Nothing in ICANN Staff's denial of the Second Request demonstrates that ICANN Staff did not appreciate the complexity of the Requestors' dispute. The Board agrees with the BAMC that there is no evidence that ICANN Staff failed to consider this information.

          In any event, the BAMC concluded that information regarding the Requestors' history of disputes and resolution attempts was not material or relevant to ICANN Staff's decision on the Second Request.12 The Board agrees. ICANN Staff denied the Second Request consistent with ICANN's rule against granting more than one request to postpone the auction for any contention set, regardless of the reason for the request.13

        2. ICANN Staff Did Not Violate ICANN Policies Favoring Voluntary Settlements.

          The Requestors claim that ICANN Staff's denial of the Second Request violated ICANN organization's policies favoring voluntary settlements of contention sets and treating contention set auctions as a means of last resort only.14 The BAMC concluded, and the Board agrees, that the denial of the Second Request was consistent with and did not violate ICANN's policy favoring the voluntary resolution of string contentions and treating auction as a tie-breaker method only.15

          In their Rebuttal, the Requestors challenge the BAMC's reliance on the Applicant Guidebook's statement that postponement is "a one-time option; ICANN will grant no more than one such request for each set of contending applications."16 Requestors assert that this language does not apply to them because it is in the section of the Applicant Guidebook discussing Community Priority Evaluation procedures when "more than one community-based application is found to meet the criteria" for Community Priority, and neither of the community-based applications for .MERCK met the criteria for Community Priority.17

          However, although the Applicant Guidebook's discussion of the one-postponement rule comes in the section of Community Priority Evaluations, the language in the Applicant Guidebook makes clear that mutual requests for postponements of auctions will be granted once and only once. Further, and notably, as the BAMC pointed out and Requestors acknowledge, the Applicant Guidebook is not the only document referencing that one-postponement only rule. ICANN's "Auction Date Advancement/Postponement Request Form" (the Postponement Request Form) explains that "ICANN may accommodate one postponement request per contention set."18 As the BAMC noted, the current version of the Auction Rules for New gTLDs refers to the Postponement Request Form.19 The Postponement Request Form "provides applicants who have received an intent to Auction notification the ability to request an advancement or postponement to their scheduled Auction Date" if all contention set members agree on postponing (or advancing) the auction date.20 The form is available for postponement requests from any group of applicants in any contention set (so long as all members of the contention set agree to the postponement). The Postponement Request Form does not limit the one-postponement rule to any certain type of contention set – rather, it is applicable to all.21

          The Board concludes that the Postponement Request Form evidences ICANN organization's rule to grant only one mutually requested postponement of an auction, and that the references to postponing auctions in the Applicant Guidebook and the Auction Rules do not evidence an intent to limit the applicability of that rule to certain types of contention sets, or to permit multiple postponements for certain types of contention sets.

          The Requestors also suggest in their Rebuttal that although they have sought to resolve the .MERCK contention set in good faith during the more than five months (now more than eight months) since the auction for the contention set was first scheduled on 2 May 2019, "the picture is far more complex" – presumably suggesting that five months is not enough time.22 However, it should be noted that the Requestors have had much more than five months to resolve their disputes. The Requestors have been involved in disputes with each other for decades. The Requestors have known that their applications were destined for an auction if they did not reach a private resolution since their 2012 submission of competing .MERCK applications; or, at the very least, since March 2013 when Merck KGaA filed Legal Rights Objections against Merck Registry Holdings, Inc.'s application specifically relating to the use of the "Merck" name.23 As such, this argument by the Requestors does not support reconsideration.

          The BAMC concluded and, for the reasons stated above and those set forth in the BAMC Recommendation, the Board agrees that the denial of the Second Request, and ICANN's rule against second postponements of contention set auctions more broadly, is consistent with and does not violate ICANN's policy favoring the voluntary resolution of string contentions and treating auction as a tie-breaker method only. In addition, it should be noted that the rule against second postponements does not prevent settlements, but merely prevents parties from indefinitely prolonging gTLD disputes by providing an auction deadline. This use of the auction process to provide a backstop if settlement efforts fail after a reasonable time is consistent both with ICANN's pro-settlement policy and with its designation of auctions as a method of last resort to resolve string contention.

        3. ICANN Staff Did Not Violate ICANN's Commitment to Apply Policies Neutrally and Objectively.

          The Requestors claim that ICANN Staff's denial of the Second Request violated ICANN's Commitment to make "decisions by applying documented policies neutrally and objectively with integrity and fairness." The BAMC concluded, and the Board agrees, that neither ICANN's Commitment to apply policies neutrally nor any other Commitment precludes the use of ICANN's rule against second postponements or requires the use of case-by-case discretion in all instances.

          In their Rebuttal, Requestors suggest that, "given the uniqueness of the circumstances here," ICANN Staff were required to apply "flexibility and discretion" in considering the Second Request, even if ICANN organization would otherwise prohibit second postponements.24 The "unique[] . . . circumstances" present here, according to the Requestors, are that the two Requestors are "completely aligned" insofar as they "are in complete alignment to postpone the auction."25 But those circumstances are not unique; agreement among applicants is a prerequisite for requesting any auction postponement.26 The Board concludes that this argument does not support reconsideration.

          The Requestors disagree with the BAMC's conclusion that applying a one-postponement rule "treats every request for a second postponement equally, by providing that all such requests will be denied."27 The Requestors suggest that ICANN Staff's denial of the Second Request has the effect of "discriminating against [the Requestors]."28 As the Requestors note, ICANN's Commitment to make "decisions by applying documented policies neutrally and objectively with integrity and fairness"29 "specifically aims at preventing discrimination 'singling out any particular party'."30 However, the Requestors have not demonstrated that ICANN Staff singled out any particular party for disparate treatment, because they have not identified any party that ICANN Staff treated differently nor have they identified any instance where ICANN suggested its policy was other than allowing just one mutually requested auction postponement. The Board agrees with the BAMC's conclusion that the single-postponement rule in fact allows ICANN Staff to treat all second postponement requests equally. Accordingly, this argument does not support reconsideration.

        4. The Requestors' Disagreement with the Rule Against Second Postponements of Auctions is Not a Basis for Reconsideration.

          The Requestors essentially disagree with ICANN organization's rule denying second postponements in all cases.31 The BAMC concluded that none of the Requestors' arguments demonstrated that the rule contradicts ICANN's Mission, Commitments, Core Values, and/or established ICANN policy(ies), or otherwise provided a basis for reconsideration of the denial of the Second Request.32

          On rebuttal, the Requestors clarify that they are not challenging the rule against second postponements itself but rather, they are challenging "the motivation of ICANN Staff to deny the second postponement of the auction."33 For the reasons set forth in the BAMC's Recommendation, the Board concludes that ICANN Staff's motivation in denying the Second Request was to comply with ICANN organization's one-postponement rule. The Board concludes that the Requestors' arguments concerning ICANN Staff's motivation do not support reconsideration.

        5. The Requestors' Update Concerning Settlement Discussions.

          In the Rebuttal, the Requestors provide an update on the status of the ongoing litigation that they assert is related to their negotiations concerning .MERCK. The Requestors initially claim that they are "very close to the resolution" of their disputes, yet their new projected dates for the conclusion of the outstanding litigations in Australia, China, India, Switzerland, the U.S., and the U.K. is approximately June 2020; and that "[o]nce we have the above-mentioned decisions and hearings, we will be in a better position to seek to finalize a settlement." The Requestors currently request until the end of August 2020 to attempt to resolve the string contention.34

          The Board believes that directing ICANN organization to obtain another update in the near future is unlikely to produce new or different information. Nonetheless, the Board acknowledges the Requestors' offer to "provide the Board with a more detailed update on the court rulings which are expected in January 2020 and the progress they have made toward settlement."35 Accordingly, for good measure, the Board has directed the President and CEO, or his designee(s), to seek an update from the Requestors on: (i) whether the Requestors have received any of the court rulings that the Requestors expect in January 2020; and (ii) what progress, if any, the Requestors have made toward settlement. If the Requestors jointly declare they have made progress since filing Request 19-4 and ICANN organization is satisfied that the Requestors are very close to private resolution, the Board will ask ICANN organization to consider providing the Requestors with some form of discretionary relief that could allow them a limited amount of time to finalize a settlement. If the Requestors do not provide an additional update regarding their settlement progress and/or if ICANN organization is not satisfied that the Requestors are very close to private resolution, the Board directs the President and CEO, or his designee(s), to continue processing the .MERCK applications, including scheduling an auction if ICANN organization deems it appropriate.

          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. This accountability includes 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. This action should have 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.

Published on 28 January 2020


1 https://www.icann.org/en/system/files/files/idn-vip-integrated-issues-final-clean-20feb12-en.pdf

2 https://www.icann.org/en/system/files/files/draft-lgr-procedure-20mar13-en.pdf

3 https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en

4 CCT-RT Implementation Shepherds are former CCT-RT members who volunteered to provide clarifications, on an as-needed basis, on recommendations' intent, rationale, facts leading to conclusions, timeline, and measures of implementation. See https://community.icann.org/display/CCT/Implementation+Shepherds for more information.

5 Request 19-4, § 8, at Pgs. 7-8.

6 See id.

7 BAMC Recommendation at Pgs. 9-10.

8 Rebuttal, at Pgs. 3-4.

9 Request 19-4, § 8, at Pg. 7.

10 BAMC Recommendation, at Pgs. 4 n.28, 9.

11 Rebuttal, at Pg. 4. The Requestors also assert that the BAMC's statement, in its Recommendation, that the Requestors "each have trademark rights involving the word 'Merck,' which have been and continue to be the subject of litigation in multiple jurisdictions for many decades," indicates that ICANN Staff failed to consider the Requestors' history when Staff evaluated the Second Request, because "all of the current court cases" were initiated after the Requestors applied for the .MERCK gTLD in 2012. Rebuttal, at Pg. 3. Whether the Requestors' legal fights began seven years ago or many decades ago is not material, the BAMC and ICANN Staff were well aware of the Requestors' history of disputes. More important, the Board agrees with the BAMC that the Requestors' history (however long it extends) was not material to the Second Request.

12 BAMC Recommendation, at Pgs. 9-10.

13 Id.

14 Request 19-4, § 8, at Pgs. 8-11.

15 See BAMC Recommendation at Pg. 11-12.

16 Rebuttal, at Pg. 4, quoting BAMC Recommendation, at Pg. 9.

17 Id., at Pg. 5.

18 Postponement Request Form, https://newgtlds.icann.org/en/applicants/auctions/date-advancement-postponement-form-09nov17-en.pdf (emphasis in original).

19 BAMC Recommendation at 10 n.53, citing Auction Rules for New gTLDs (3 Nov. 2014), ¶ 10, https://newgtlds.icann.org/en/applicants/auctions/rules-03nov14-en.pdf

20 Postponement Request Form.

21 The Board acknowledges that the Auction Rules state that applicants may submit a postponement request through the ICANN Customer Portal without using the Postponement Request Form under certain circumstances. Auction Rules, ¶ 10. But the Auction Rules' discussion of postponement does not indicate that ICANN may grant multiple postponements for the same contention set. See id. The Board concludes that the Auction Rules do not reflect a rule favoring or allowing multiple postponements of a contention set auction.

22 Rebuttal, at Pg. 10.

23 Expert Determination Legal Rights Objections in March 2013, https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0009.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0010.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0011.pdf. And the Requestors were again alerted to the eventual need to resolve the contention set either via private resolution or by auction when Merck KGaA submitted Reconsideration Request 16-12 in August 2016. BAMC Recommendation, at Pgs. 11-12.

24 Rebuttal, at Pgs. 6-7.

25 Id.

26 Auction Rules, ¶ 10; see also Postponement Request Form.

27 Rebuttal, at Pg. 7, citing BAMC Recommendation, at Pg. 14.

28 Id.

29 ICANN Bylaws, Art. 1, § 1.2(a).

30 Rebuttal, at Pg. 7.

31 Request 19-4, § 8, at Pgs. 8, 10, 13, 14.

32 BAMC Recommendation, at Pg. 15.

33 Rebuttal, at Pg. 8.

34 Rebuttal, at Pg. 10.

35 Id.

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