Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

董事会的活动和会议

查看 ICANN 董事会近期活动和会议的措施和决策记录。

会议记录 | ICANN 董事会例行会议 2019 年 03 月 14 日

当地时间 2019 年 3 月 14 日 16:00，ICANN 董事会在日本神户召开了现场例行会议。

主席谢林·查拉比 (Cherine Chalaby) 准时宣布会议正式开始。

除主席外，以下董事也参加了全部或部分会议：贝基·伯尔 (Becky Burr)、玛盾·波特曼 (Maarten Botterman)、罗恩·达席尔瓦 (Ron da Silva)、萨拉·多伊奇 (Sarah Deutsch)、克里斯·狄思潘（Chris Disspain，副主席）、艾芙丽·多利亚 (Avri Doria)、拉斐尔·利托·伊瓦拉 (Rafael Lito Ibarra)、丹科·杰夫托维克 (Danko Jevtovic)、卡勒德·库巴 (Khaled Koubaa)、前村昌纪 (Akinori Maemura)、马跃然（Göran Marby，总裁兼首席执行官）、尼戈尔·罗伯茨 (Nigel Roberts)、里昂·桑切斯 (León Sanchez)、马修·希尔斯 (Matthew Shears) 以及特里普蒂·辛哈 (Tripti Sinha)。

以下董事会联络人参加了全部或部分会议：哈罗德·阿维斯特兰（Harald Alvestrand，IETF 联络人）、玛娜尔·伊斯梅尔（Manal Ismail，GAC 联络人）、梅里克·科欧（Merike Kaeo，SSAC 联络人）以及凯夫·兰吉巴（Kaveh Ranjbar，RSSAC 联络人）。

秘书长：约翰·杰弗里（John Jeffrey，总法律顾问兼秘书长）。

 

  1. 认可议程：
    1. 批准会议记录
    2. 批准修订意见，执行 Verisign 提出的注册管理机构服务请求 (Registry Service Request)，授权释放单字符、二级域“O.COM”的注册
    3. 延期执行详尽 WHOIS 的政策实施
    4. 任命 2019 财年独立审计师
    5. 接受组织效率委员会章程修订
    6. 向根服务器系统咨询委员会 (RSSAC) 任命根服务器运营商组织代表
    7. 批准对 IANA 域名职能合同进行的修订
    8. 感谢第 64 届 ICANN 会议的当地主办机构
    9. 感谢第 64 届 ICANN 会议的赞助商
    10. 感谢第 64 届 ICANN 会议的口译员、工作人员以及会议和酒店团队
  2. 主要议程：
    1. 关于管理 IDN 变体 TLD 的建议
    2. 准备实施新 gTLD 的后续程序
    3. 将 .VU（瓦努阿图）顶级域转让给电信无线电通信和广播监管机构 (TRBR)
    4. 对重审请求 16-5：DotMusic Limited 的考量
    5. 对 .AMAZON 的考量
    6. 接受提名委员会 (NomCom) 第二轮组织审核 —《最终报告和建议》
    7. 关于组建 IANA 命名职能审核小组的后续步骤
    8. 其他事务
      1. 域名冲突分析项目 — 第一项研究

  1. 认可议程：

    主席宣布会议开始，并介绍了认可议程的事项。主席询问是否有任何董事会成员希望将“认可议程”中的任何项目移至主要议程。艾芙丽·多利亚要求将关于“接受提名委员会 (NomCom) 第二轮组织审核 —《最终报告和建议》”的项目从认可议程移至主要议程。克里斯·狄思潘要求将“关于组建 IANA 命名职能审核小组的后续步骤”项目从认可议程移至主要议程。

    罗恩·达席尔瓦提出了动议，利托·伊瓦拉进行了附议。随后，主席发起投票，董事会采取了以下行动：

    1. 批准会议记录

      第 2019.03.14.01 号决议：董事会批准 2019 年 1 月 16 日 ICANN 董事会特殊会议和 2019 年 1 月 27 日 ICANN 董事会例行会议的会议记录。

    2. 批准修订意见，执行 Verisign 提出的注册管理机构服务请求 (Registry Service Request)，授权释放单字符、二级域“O.COM”的注册

      鉴于 ICANN 组织已根据 .COM 注册管理机构协议第 3.1(d)(iii) 和 3.1(d)(iv) 条的要求以及注册管理机构服务评估政策，将 Verisign .COM 注册管理机构协议的拟议修正案作为一项注册管理机构服务进行了评估，并且 ICANN 组织未发现重大安全性或稳定性问题，且已发布该拟议修正案以征询公众意见。

      鉴于 ICANN 组织确定拟议的注册管理机构服务可能引发重大竞争问题并已将此事提交给美国司法部，而美国司法部反垄断司已向 ICANN 组织通知其无意就此事展开调查。

      鉴于 ICANN 组织已于 2018 年 5 月 10 日至 2018 年 6 月 20 日对拟议修正案开展了公共评议，以实施 Verisign 获批的注册管理机构服务请求，释放单字符名称 O.COM 用于注册，并且已向董事会提交了意见的总结和分析。

      鉴于释放单字符域 O.COM 的提议与 GNSO 保留名称工作组的建议一致。

      鉴于 ICANN

      董事会认真考虑了收到的公众意见以及 ICANN 组织对意见的总结和分析。

      鉴于 ICANN 董事会认定，允许释放单字符 O.COM 域名的拟议修正案仅限于此特定域名的独特情况，并且修正案的获批不会建立适用于其他情况的先例。

      兹此发布第 2019.03.14.02 号决议：批准 .COM 注册管理机构协议的修正案，同意在 .COM 域名空间中释放单字符 O.COM 域名，并授权总裁兼首席执行官或其指定人员采取适当行动来实施该修正案。

      第 2019.03.14.02 号决议的理由

      为什么董事会要在当下解决此问题？

      2017 年 11 月，Verisign 提交了一份注册管理机构服务请求，要求通过拍卖方式试行释放一个带有单字符标签的 .COM 域名 O.COM，将拍卖收益用于互联网社群的公益领域，同时遵守 ICANN 组织的单字符二级域名 (SCSLD) 分配框架。

      ICANN 组织已对拟议的注册管理机构服务进行了审核，未发现重大的安全性或稳定性问题。但是，ICANN 组织确定拟议的注册管理机构服务可能会引发重大竞争问题。2017 年 12 月 7 日，ICANN 组织将此事提交给美国司法部。2017 年 12 月 14 日，美国司法部反垄断司通知 ICANN 组织，其无意就此事展开调查。

      在初步裁定批准拟议的注册管理机构服务后，ICANN 组织发布了对 .COM 注册管理机构协议的拟议修正案，以便在 2018 年 5 月 10 日至 2018 年 6 月 20 日期间就该服务的实施征询公众意见。

      拟议修正案遵循 GNSO 保留名称工作组、GNSO 理事会和 ICANN 组织对单字符域名的分析和建议以及社群的意见，并与 ICANN 董事会批准释放其他传统通用顶级域 (gTLD) 中的单字符名称相一致。迄今为止，ICANN 董事会已批准释放许多传统 gTLD 中的单字符名称，这些传统 gTLD 包括 .ORG、.BIZ、.INFO、.MOBI 和 .PRO。此外，对于作为新 gTLD 项目的一部分引入的 gTLD，不需要保留单字符名称。

      ICANN 组织已采取措施评估和考虑拟议的修正案和社群的反馈，并已将相关结果提交给 ICANN 董事会，以便其在做出决定之前进行审核和考量。

      正在考虑的提案是什么？

      根据拟议的修正案，单字符域名 O.COM 将通过拍卖流程进行分配，并由第三方服务提供商管理。Verisign 不会直接或间接从 O.COM 的出售、分配、转让或续订中获得任何收益，只会收取 O.COM 注册的标准注册费，即 7.85 美元。从 O.COM 拍卖中获得的收益将提供给一个或多个非营利组织或其继任者，主要用于互联网社群的公益领域。拍卖所得收益不会直接或间接用于使 Verisign、其附属机构或其董事、高级职员或员工受益。任何潜在注册人都可以参与拍卖流程，如果获得该名称，可选择任何 ICANN 认证注册服务机构来管理 O.COM 的注册。对于注册人如何选择 .COM 的 ICANN 认证注册服务机构，不会受到任何限制。

      中标的注册人必须：(i) 在被确定为中标者之日起十四 (14) 个日历日内缴纳中标价格的全部金额，以及 (ii) 承诺在五 (5) 年初始注册期到期后，在续订域名的每年向信托支付中标价格首期付款的百分之五 (5%)（每年支付的款项称为“后续分期付款”），直至中标注册人续订单该字符域名的第二十五 (25) 年（包括该年度）。后续分期付款旨在鼓励向非营利组织提供持续的资金流，直至后续分期付款到期。举例来说，如果拍卖时间为 2020 年，中标价格为 10,000 美元，那么单字符域名中标价格的首期付款为 10,000 美元，于 2020 年支付；五 (5) 年初始期之后，每年的后续分期付款为 500 美元（即中标价格首期付款的 5%），从 2026 年一直支付至 2045 年。

      咨询了哪些利益相关方或其他方？

      ICANN 组织就拟议修正案征询了公众意见，公共评议期为 2018 年 5 月 10 日至 2018 年 6 月 20 日。该提案收到了来自二十四 (24) 个独立实体的二十九 (29) 条评论。

      社群提出了哪些疑虑或问题？

      提交的评论大致可分为以下几类，下文对每类评论进行了详细说明：

      1. 表示支持拟议的修正案以释放 O.COM。
      2. 担心 O.COM 的释放可能会产生安全性和稳定性问题。
      3. 担心对于释放 O.COM 的拟议“试行”要求会为未来释放单字符 .COM 域名或整个 .COM 域名空间设置先例。
      4. 担心 Verisign 拟议由注册人为续订 O.COM 而支付的“后续分期付款”可能是 Verisign 提高整个 .COM 域名空间续订费率的工具。
      5. 担心 Verisign 在分配名称后对 O.COM 域名施加的转让限制。
      6. 担心拟议修正案中未提出在释放 O.COM 后对某些权利进行保护。
      7. 担心拍卖流程和 Verisign 所提议的由拍卖提供商针对释放 O.COM 而规定的资格预审要求，并担心该流程缺乏透明度。
      8. 对于修正案提议的 O.COM 拍卖之后拟议资金分配的建议。

      一些评论者针对释放单字符 .COM 名称和将拍卖收益用于支持互联网公益的提议表达了积极反馈，并就如何使用该收益提供了额外的建议。评论者一致关注的一个主题在于，从拍卖提供商的选择到管理域名释放的拟议流程，整个拍卖流程都需要保持透明。

      两位评论者表示，释放之后，O.COM 可能会在 .COM 域名空间引起安全性和稳定性问题。此外，评论者表达了对 Verisign 提议的拍卖和释放 O.COM 域名的方法的担忧，以及对 O.COM 的拟议要求的担忧，因其与当前 .COM 域名注册和续订的方式不一致，并且缺乏释放 O.COM 后的某些权利保护措施。

      公共评议期提出的安全性和稳定性问题主要在于释放拉丁文字版本的单字符“O.COM”域名可能存在“完整文字混淆”，因为希腊文字和西里尔文版本的“O.COM”已存在于 .COM 域名空间中。经过内部评估后，已确定该风险不会超过其他 TLD 中已释放的其他单字符域名。

      一些评论表示担心 O.COM 释放的拟议要求可能为未来释放单字符 .COM 域名或整个 .COM 域名空间设置先例。具体而言，评论者表示，Verisign 提议的由注册人为续订 O.COM 而支付的“后续分期付款”会让 Verisign 有机会针对将来在 .COM 域名空间中启动的其他单字符域名或所有 .COM 域名收取额外费用或额外续订费用。ICANN 组织指出，Verisign 提议的 RSEP 以及 .COM 注册管理机构协议的拟议修正案可确保 Verisign 仅收取 O.COM 初始注册及所有后续续订的标准注册费，这些注册费将符合 .COM 注册管理机构协议第 7.3(d) 条中的注册管理机构费用定价规定。截至提案提交日期，该注册费（定义为 .COM 注册管理机构协议中的最高价格）为 7.85 美元。Verisign 将获得的唯一续订费用是续订时的标准续订费。中标注册人所需支付的“后续分期付款”旨在“向非营利组织提供持续的资金流，直至后续分期付款到期”。

      评论者还表示担心 Verisign 拟议在分配名称后对 O.COM 域名施加的转让限制，并表示这会给 .COM 域名空间带来不必要的复杂性。此外，评论者还担心，如果允许此限制，Verisign 可能会将限制扩展到尚未释放的单字符 .COM 域名。评论者指出，鉴于宝贵的 .COM 域名空间中单字符名称的稀缺性，应允许中标注册人使用他们认为合适的名称。在对公众意见进行审核之后，Verisign 自愿从拟议修正案中删除了拟议的注册人之间的转让限制。

      其他评论者还担心缺乏针对 O.COM 释放的某些权利保护机制 (RPM)，并担心 O.COM 被添加到.COM 域名空间后可能引起安全性和稳定性问题。但是，.COM 注册管理机构协议并未要求在发布任何保留名称之前提供日升期。此外，已提交并在随后获得董事会批准的针对 .BIZ (2008)、.INFO (2010) 和 .ORG (2011) 释放单字符和双字符保留名称的 RSEP 请求也未包括日升期。统一域名争议解决政策适用于因 .COM 域名空间中包括 O.COM 在内的任何名称分配而产生的任何商标相关争议。

      董事会审核了哪些重要材料？

      在审议过程中，董事会审核了诸多材料，包括但不限于以下材料和文档：

      董事会认为至关重要的因素有哪些？

      董事会仔细审议了就关于实施 Verisign 的注册管理机构服务请求以释放单字符名称 O.COM 用于注册的修正案收到的公众意见，以及对这些意见的总结和分析。董事会还在与 ICANN 组织的双边协商中讨论了注册管理运行机构达成一致的条款。

      董事会感谢社群为审查关于实施释放 O.COM 的拟议修正案而投入的时间。此外，董事会的考量基于社群的参与和反馈，这些参与和反馈提供了富有洞见的建议，以支持 Verisign 提议的将 O.COM 拍卖所得收益用于互联网社群公益的方法。

      董事会还承认一些社群成员对单字符“O.COM”释放后可能产生的“完整文字混淆”以及单字符域名释放可能带来安全性和稳定性问题的担忧。但是，董事会承认，传统 gTLD 和新 gTLD 中目前均提供其他单字符域名，并且整个社群仍在继续努力缓和所有完整文字混淆域名可能产生的安全性和稳定性问题。其中包括 IDN 指南工作组 (IDNGWG) 发布的《国际化域名实施指南》最终提案草案 4.0 版（IDN 指南第 4 版），其中建议了旨在最大限度降低域名抢注和消费者混淆风险的做法。董事会指出，IDN 指南草案第 4 版“鼓励 TLD 注册管理机构对注册进行额外限制，以尽量减少完整文字混淆…”，但并未规定具体的缓解措施，并且 IDN 指南第 4 版尚未被董事会采纳。ICANN 组织的惯例是遵守现有的政策和程序，并且只有在待定的社群建议经过采纳和实施后，才会应用其中的要求。最近，董事会在 2018 年 9 月的格瓦尔工作坊上讨论了当正在进行的社群工作可能导致流程更改而影响请求时，ICANN 组织应如何处理签约方提出的请求。

      董事会还认可社群提出的担忧，即拟议的通过试行拍卖流程释放 O.COM 的各方面要求与 .COM 域名空间中其他域名的要求不同，并可能在当前和未来影响 .COM 域名空间中的其他域名。董事会承认社群提出的担忧，并进一步认可 Verisign 通过试行流程释放 O.COM 的方法，因为这可以让 Verisign 和潜在注册人有机会获得有关该流程的宝贵见解。如上所述，拟定服务不会影响 .COM 域名空间中任何其他域名注册的现有功能、方法、定价、程序或规范。此外，Verisign 受 .COM 注册管理机构协议条款的约束，O.COM 的释放不会改变这些承诺。董事会进一步认可 Verisign 对拟定修正案的更新，即取消转让限制，以回应社群提出的担忧。

      董事会还承认对拟议修正案中的整体拍卖和拍卖流程提出的担忧，并指出拟议的拍卖流程类似于大多数注册管理运行机构管理和拍卖域名的方式。此外，传统 TLD（如 .BIZ、.INFO 和 .ORG）的注册管理运行机构也使用类似流程来拍卖其单字符和双字符 TLD。所有注册管理运行机构（无论是传统 TLD 还是 gTLD）都可以在不受监管或限制的情况下拍卖其 TLD，并且很少提前披露拍卖详情或向拍卖提供商支付的费用。

      董事会进一步承认评论者针对 Verisign 拟议的 O.COM 释放计划缺乏新 gTLD 注册管理运行机构用于支持其 TLD 的 RPM（权利保护机制）的担忧。评论者建议，随着 O.COM 的释放，Verisign 应承担与新 gTLD 运营商相同的义务，即设置 90 天的日升期。虽然董事会承认部分社群成员对于 Verisign 拟议的 .COM 释放计划缺乏 RPM 的担忧，但是 .COM 注册管理机构协议并未要求在发布任何保留名称之前提供日升期。此外，已提交的要求修订注册管理机构协议并在随后获得董事会批准的针对 .BIZ (2008)、.INFO (2010) 和 .ORG (2011) 释放单字符和双字符保留名称的 RSEP 请求也未包括日升期。统一域名争议解决政策适用于因 .COM 域名空间中包括 O.COM 在内的任何名称分配而产生的任何商标相关争议。

      是否会对社群产生积极或者消极影响？

      预计董事会批准释放单一字符 O.COM 域名用于注册的拟议修正案将会带来积极影响。正如一些社群成员在公共评议期所指出的，这对于释放更多单字符域名而言是一个积极步骤，特别是在 .COM 域名空间中。此外，评论者支持 Verisign 所提出的，将 O.COM 拍卖所得收益用于互联网社群公益的方法，并鼓励 Verisign 在收益分配方面保持透明。

      是否会在财务方面对 ICANN 组织（例如，战略规划、运营规划、预算）、社群和/或公众产生影响或不良后果？

      释放单字符 O.COM 用于注册预计不会对 ICANN 组织产生重大的财务影响。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题？

      如上所述，公共评议期有评论者提出了关于释放 O.COM 是否可能导致安全性或稳定性问题的疑问。提出的担忧涉及拉丁文字“O.COM”与 .COM 域名空间中已有的希腊文和西里尔文字符可能存在“完整文字”混淆，并认为 O.COM 的释放可能与 IDN 指南草案第 4 版相冲突。ICANN 组织已向董事会确认，IDN 指南草案第 4 版“鼓励 TLD 注册管理机构对注册进行额外限制，以尽量减少完整文字混淆…”，但并未规定具体的缓解措施，O.COM 的释放不会与 IDN 指南第 4 版冲突。此外，由于 ICANN 组织仍在继续定义实施计划以确保顺利过渡到新指南，因此董事会尚未采纳 IDN 指南第 4 版。IDN 指南第 4 版预计需要将现有域名视为例外，“当先前已存在的域名要求注册管理机构对任何指南进行过渡性例外处理时，必须同时在网上公布该例外行动的条款，包括解决此类过渡事项的时间表”，并希望 Verisign 在适当时遵守这一要求。

    3. 延期执行详尽 WHOIS 的政策实施

      鉴于详尽 WHOIS 过渡政策要求 Verisign 从 2019 年 11 月 30 日开始接受注册服务机构提交的有关 .COM 和 .NET 名称的“详尽”注册数据，2020 年 5 月 31 日之前的所有新域名注册必须作为“详尽”注册提交至注册管理机构，且现有域名的所有相关注册数据必须在 2020 年 11 月 30 日之前由“简略”向“详尽”转变。

      鉴于在为完成部署以接受详尽 WHOIS 数据做准备期间，Verisign 提议对有关 .COM 和 .NET 的注册管理机构-注册服务机构协议进行修改。

      鉴于注册服务机构利益相关方团体根据与欧盟《通用数据保护条例》、数据的处理以及对注册服务机构强加的新要求和义务有关的问题，就 Verisign 提议的修改表达了担忧。

      鉴于 ICANN 组织继续促进 Verisign 与注册服务机构利益相关方团体之间的讨论，旨在就为了实施详尽 WHOIS 过渡政策而提议对注册管理机构-注册服务机构协议进行的修改达成一致。

      鉴于 Verisign 和注册服务机构利益相关方团体需要额外的时间来就为了实施详尽 WHOIS 过渡政策而提议对适用的注册管理机构-注册服务机构协议进行的修改达成一致。

      鉴于推迟执行期将让 ICANN 社群和董事会有时间考量快速政策制定流程 (EPDP) 关于 gTLD 注册数据临时规范的最终报告。

      鉴于额外留出的时间将让受影响的签约方和 ICANN 组织有更多时间评估 EPDP 的建议对详尽 WHOIS 过渡政策的任何潜在影响。

      兹此发布第 2019.3.14.03 号决议：授权总裁兼首席执行官或其指定人员将详尽 WHOIS 过渡政策的合规工作分别推迟到 2019 年 11 月 30 日、2020 年 5 月 31 日和 2020 年 11 月 30 日执行。

      第 2019.03.14.03 号决议的理由

      详尽 WHOIS 过渡政策规定采用分阶段方法，使 .COM 和 .NET 注册管理机构实现由“简略”WHOIS 向“详尽”WHOIS 的过渡。这三个阶段是：

      1. 注册管理运行机构 (RO) 开始接受注册服务机构提交的详尽 WHOIS 数据；
      2. 新的 .COM 和 .NET 域名注册作为详尽注册处理；以及
      3. RO 开始接受注册服务机构提交的详尽 WHOIS 数据之日后一年，实现所有现有域名注册数据由“简略”向“详尽”数据的完全过渡。

      详尽 WHOIS 过渡政策要求 Verisign 从 2019 年 5 月 31 日起开始接受注册服务机构提交的“详尽”注册数据，从 2019 年 11 月 30 日开始，注册服务机构必须向 Verisign 提交所有新域名注册的详尽注册数据，且所有现有域名注册数据必须在 2020 年 5 月 31 日之前实现由“简略”向“详尽”的过渡。在为接受详尽 WHOIS 数据做准备期间，Verisign（.COM 和 .NET 的注册管理运行机构）提议对有关 .COM 和 .NET 的注册管理机构-注册服务机构协议进行修改，以便为接受数据提供必要的法律框架。虽然详尽 WHOIS 共识性政策也适用于 .JOBS TLD，但 .JOBS 的注册管理运行机构 Employ Media 并未要求必须修改注册管理机构-注册服务机构协议才能开始接受详尽注册数据，注册服务机构已经根据该政策开始提交 .JOBS 的详尽注册数据。

      依据注册管理机构-注册服务机构协议修订程序，ICANN 组织一直在促进 Verisign 与注册服务机构利益相关方团体之间的讨论，旨在就提议对注册管理机构-注册服务机构协议进行的修改达成一致，但相关各方尚未达成一致。此外，社群正在通过 GNSO 的 EPDP 制定永久性共识性政策，以取代或确认 gTLD 注册数据临时规范。

      董事会当前正在采取行动，授权 ICANN 总裁兼首席执行官将执行详尽 WHOIS 过渡政策的合规工作的时间推迟 180 天。这将让社群和董事会有额外的时间来考量 EPDP 最终报告中的建议。此推迟还将让受影响的签约方和 ICANN 组织有时间评估 EPDP 的建议对详尽 WHOIS 过渡政策的任何潜在影响。

      如果 EPDP 团队建议对 gTLD 注册数据临时规范进行重大更改，则有可能需要再次延期。

      董事会在考虑该事项时参考了多项重要材料，包括：

      董事会采取的行动预计不会对 ICANN 产生尚未纳入当前预算的财务影响。此项行动符合公共利益和 ICANN 的使命，因为它有助于确保一致和协调地实施 gTLD 政策。

      该决议属于组织管理职能，无需征询公众意见。

    4. 任命 2019 财年独立审计师

      鉴于《ICANN 章程》第 22.2 条 (http://www.icann.org/general/bylaws.htm) 要求在财年结束后，必须由注册执业会计师审计 ICANN 账册，而会计师应由董事会任命。

      鉴于董事会审计委员会已讨论了 2019 年 6 月 30 日结束的财年的独立审计机构聘请工作，并建议董事会授权总裁兼首席执行官或其指定人员采取一切必要措施聘请 BDO LLP 和 BDO 成员机构。

      兹此发布第 2019.03.14.04 号决议：董事会授权总裁兼首席执行官或其指定人员采取所有必要措施，聘请 BDO LLP 和 BDO 成员公司作为 2019 年 6 月 30 日结束财年的财务报表的审计机构。

      第 2019.03.14.04 号决议的理由

      自 2014 财年审计以来，审计机构 BDO LLP 和 BDO 成员机构一直是 ICANN 的独立审计机构。根据组织的报告和审计委员会对所执行的工作的评估，委员会建议董事会授权总裁兼首席执行官或其指定人员采取一切必要措施聘请 BDO LLP 和 BDO 成员机构担任 ICANN 2019 财年的年度审计机构，以应对所有管辖区的任何年度独立审计要求。

      这进一步加强了 ICANN 对其章程和流程的问责制，而公众也将获许访问独立审计机构的工作成果。做出此决定与 ICANN 的使命一致并符合公共利益，因为聘请独立审计机构是履行 ICANN 应尽的财务报表审计义务，并帮助以更负责的方式服务 ICANN 利益相关方。

      按照预期，此决定将对 ICANN 产生财务影响。这不会对域名系统的安全、稳定与弹性产生直接影响。

      这属于组织管理职能，无需征询公众意见。

    5. 接受组织效率委员会章程修订

      鉴于 ICANN 董事会组织效率委员会目前负责按照《ICANN 章程》的规定监督组织审核和特定审核。根据 IANA 管理权移交后章程第 18 条，ICANN 还负责定期和特殊的 IANA 域名职能审核，旨在根据 IANA 域名职能合同和 IANA 域名职能工作声明审核 PTI 的表现。截至目前，董事会的任何委员会均未被指定监督责任，因为它与 IANA 命名职能审核 (IFR) 相关。

      鉴于组织效率委员会已提议对其现有章程进行修订，以反映 IFR 的监督责任。

      鉴于负责审议委员会章程的董事会治理委员会同意 OEC 的提议，并建议董事会通过修订后的 OEC 章程。

      兹此发布第 2019.03.14.05 号决议：董事会兹此通过对组织效率委员会章程的拟议修订。

      第 2019.03.14.05 号决议的理由

      董事会为什么要解决此问题？

      董事会要解决此问题的原因在于需批准对董事会委员会章程的修订。

      正在考虑的提案是什么？

      组织效率委员会 (OEC) 提议更改委员会的监督职责，将 IANA 域名职能审核 (IFR) 纳入其职责范围。鉴于 OEC 在特定审核和组织审核方面的现有监督职责，OEC 提议对 IFR 承担监督责任。

      董事会审核了哪些重要材料？

      董事会审核了对 2017 年 OEC 章程的拟议修订。参见参考资料附录 A（带修订标记）和附录 B（终稿）。

      是否会对社群产生积极或者消极影响？

      拟议的修订旨在确保明确性，并使章程规定的审核工作保持一致，以便始终如一地接受董事会监督。预计这些改进将对社群产生积极影响。IFR 是 ICANN 确认其附属机构兼签约机构公共技术标识符是否根据其合同适当履约，以及是否适合针对此类审核设定董事会层级的监督职责的关键方式。

      是否会在财务方面对 ICANN（战略规划、运营规划和预算）、社群和/或公众产生影响或不良后果？

      拟议变更不会在财务方面对 ICANN 的战略规划和运营规划产生影响或不良后果。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题？

      采取此行动不会产生与 DNS 相关的任何安全、稳定或弹性问题。

      这项行动是否符合 ICANN 的使命，它所服务的公共利益是什么？

      董事会的行动符合 ICANN 在其章程第 18 条中的承诺，即确保 PTI 根据 IANA 域名职能合同和 IANA 域名职能 SOW 中规定的合规要求执行 IANA 域名职能。这项行动符合公共利益，因为它可确保 ICANN 董事会监督 ICANN 和 PTI 如何实现 ICANN 按照客户和更广泛的 ICANN 社群的期望提供 IANA 域名职能服务的承诺。

      董事会采取行动前是否需要征询公众意见？

      无需公众意见。

    6. 向根服务器系统咨询委员会 (RSSAC) 任命根服务器运营商组织代表

      鉴于《ICANN 章程》要求成立根服务器系统咨询委员会 (RSSAC)，负责就互联网根服务器系统的运营、管理、安全性和整合性相关问题向 ICANN 社群和 ICANN 董事会提供建议。

      鉴于《ICANN 章程》要求 ICANN 董事会根据 RSSAC 联合主席的建议从各根服务器运营商组织中选拔任命一名 RSSAC 成员。

      鉴于，2019 年 2 月，欧洲网络协调中心 (RIPE NCC) 请求更换其在当前任期（于 2020 年 12 月 31 日到期）的余下任期内的代表。

      鉴于 RSSAC 联合主席已建议 ICANN 董事会任命一位 RIPE NCC 的代表至 RSSAC。

      兹此发布第 2019.03.14.06 号决议：ICANN 董事会任命凯夫·兰吉巴 (Kaveh Ranjbar) 至 RSSAC，任期截止日期为 2020 年 12 月 31 日。

      第 2019.03.14.06 号决议的理由

      2013 年 5 月，根服务器运营商组织同意了向 RSSAC 任命的代表的初始成员构成，且各个组织提名了一位个人。2013 年 7 月，ICANN 董事会批准了 RSSAC 的初始成员构成，对成员实行交错任期制。

      2019 年 2 月，RIPE NCC 请求更换其在当前任期（于 2020 年 12 月 31 日到期）的余下任期内的代表。

      任命 RSSAC 成员预计不会对 ICANN 组织产生任何财务影响，当前用于为 RSSAC 提供持续支持所必需的预算资源中未考虑这些财务影响。

      该决议属于组织管理职能，无需征询公众意见。RSSAC 成员的任命有助于 ICANN 组织实现加强 DNS 安全、稳定与弹性的承诺。

    7. 批准对 IANA 域名职能合同进行的修订

      鉴于《ICANN 章程》第 16.3 条要求 ICANN 和 PTI 维护 IANA 域名职能合同，以便 PTI 履行 IANA 域名职能。作为 IANA 管理权移交的一部分，ICANN 和 PTI 董事会于 2016 年批准了最初的 IANA 域名职能合同。

      鉴于 IANA 域名职能合同目前包含一个表格，其中说明了在 IANA 管理权移交流程中与多利益相关方群体约定的详细运营服务水平协议（SLA 表）。

      鉴于 ICANN 组织、PTI 和客户常任委员会 (CSC) 均已确定，每次需要修改、删除或添加单个 SLA 时都必须修改 IANA 域名职能合同，这种做法是不可持续的，并且无法满足 ICANN、PTI 或 IANA 域名职能客户的需求。因此，提议一次性修改 IANA 域名职能合同，将 SLA 表从合同中移出，并要求对所述 SLA 进行的任何更改均需遵循社群批准和发布的“IANA 域名服务水平协议修改流程”。

      鉴于 ICANN 组织、PTI 和 CSC 参与制定了 IANA 域名服务水平协议修改流程，并且 CSC 将此流程告知了 IANA 域名职能的客户。

      鉴于 ICANN 于 2019 年 1 月 7 日至 2019 年 2 月 18 日期间就 IANA 域名职能合同的拟议域名职能合同修正案征求了公众意见。

      鉴于 IANA 命名职能合同拟议修正案的公众意见论坛于 2018 年 2 月 18 日关闭，且 ICANN 收到了注册管理机构利益相关方团体关于支持拟议修正案的一条意见。意见总结和分析已于 2019 年 2 月 25 日公布并已提交到董事会。

      兹此发布第 2019.03.14.07 号决议：批准 IANA 域名职能合同的第 1 号修正案，并授权总裁兼首席执行官或其指定人员采取适当行动来最终确定并签署该协议。

      第 2019.03.14.07 号决议的理由

      客户常任委员会 (CSC) 与 ICANN 组织和 PTI 合作，根据应计运营数据的证据提出了变更建议。在提议将 SLA 从合同转移至 PTI 网页上的 SLA 表时，相关方认识到需要一套全面的 SLA 变更流程，以确保与 IANA 职能域名客户和更广泛的 ICANN 社群进行适当的磋商。

      在 2018 年 12 月 17 日召开的 CSC 会议上，CSC 批准了两个 SLA 变更流程：“IANA 域名职能服务水平协议修改流程”和“IANA 域名职能服务水平协议修改流程的修改程序”。ICANN 组织和 PTI 管理层参与了对话并同意这些流程。在修改域名职能合同之前，这些流程不会生效。

      董事会目前正在批准 IANA 域名职能合同的修正案，因为将 IANA 域名职能 SLA 从合同移至网页上的 SLA 表能让 SLA 变更更有效地满足域名客户的需求，同时遵守新的“IANA 域名服务水平协议修改流程”，以确保所有此类变更均遵循严格的流程，从而确保进行适当的社群协商并使 CSC 与 ICANN/PTI 之间达成一致。

      委员会的行动考虑了社群的意见，这些意见对 CSC 批准该修正案提供了支持，同时也考虑了 RySG 的公众意见，其中指出：“IANA 域名职能合同的这一修正案采纳了 CSC、PTI 和 ICANN 组织合作制定并达成一致的 SLA 变更流程。SLA 变更流程将让 CSC 和 PTI 能够：a) 在适当时修改 SLA；b) 在新服务上线时添加新的 SLA；以及 c) 删除不再需要的 SLA。RySG 支持并要求 ICANN 董事会批准该修正案，以便尽快处理完当前需要修改、添加或删除的 SLA。”

      本决议中所指示的相关行动不会对 ICANN 资源或 DNS 的安全性和稳定性产生任何进一步影响。该行动符合 ICANN 的使命，因为它能为 ICANN 执行 IANA 域名职能提供支持。

    8. 感谢第 64 届 ICANN 会议的当地主办机构

      董事会谨此感谢日本总务省大臣佐藤尤佳里 (Yukari Sato) 女士、神户市市长久元喜造 (Kizō Himamoto) 先生、ICANN64 当地主办委员会主席村井纯 (Jun Murai) 教授以及 ICANN64 当地主办委员会成员 GMO Internet Inc.、Japan Registry Services Co. Ltd.、Internet Initiative Japan Inc.、日本互联网协会、Internet Multifeed Co.、Interlink Co. Ltd.、NTT Docomo Inc.、电信服务协会、日本互联网络信息中心、BusinessRalliart Inc.、京都信息大学院大学、Com Laude（日本）公司、Taka Enterprise Ltd.、日本互联网服务提供商协会、WIDE 项目、NTT Communications Corporation、KDDI Corporation 以及 Nippon Telegraph and Telephone West Corporation。此外，还要感谢日本总务省、神户会议局和 Tsutomu Nakauchi 基金会的大力支持。

    9. 感谢第 64 届 ICANN 会议的赞助商

      董事会希望对以下赞助商表示感谢：Verisign、公共利益注册管理机构、Afilias plc 和 CentralNic。

    10. 感谢第 64 届 ICANN 会议的口译员、工作人员以及会议和酒店团队

      董事会对速记员、口译员、视听团队、技术团队和全体 ICANN 工作人员为会议顺利进行所付出的努力表示最深的谢意。董事会还要感谢神户 Portopia 酒店和神户国际会议中心的管理层和工作人员为召开本次会议提供了优良的场所和设施。特别感谢神户国际会议中心团队的 Omura Masatoshi、Rikako Nakanishi、Aya Fukuda、Eiji Makatsuji、Yuko Zikumaru、Tetsuya Shori 和 Lance Ferguson 以及神户 Portopia 酒店活动和 IT 工作人员 Hitoshi Nakauchi、Tsuyoshi Ito、Takahiko Kishimoto、Kenji Kino、Shingo Murakami、Takumi Nishihara、Tomoko Nishio、Tomoya Takeda、Makoto Sakai、Shohei Inoue、Yosuke Taniguchi、Rose Tanasugarn 和 Pryde Productions 的经理 Gilbert Yeo。

    董事会出席会议的所有成员投票赞成第 2019.03.14.01、2019.03.14.02、2019.03.14.03、2019.03.14.04、2019.03.14.05、2019.03.14.06 和 2019.03.14.07 号决议。决议通过。

  2. 主要议程：

    主席介绍了主要议程。

    1. 关于管理 IDN 变体 TLD 的建议

      前村昌纪介绍了此议程事项。读完拟议的决议后，前村昌纪指出，拟议的决议是社群作出巨大贡献的工作成果。董事会正应要求批准该工作产生的建议，并要求 ccNSO 和 GNSO 在制定各自的政策时考虑建议，以定义和管理当前 TLD 以及未来 TLD 申请的 IDN 变体 TLD。

      前村昌纪提出了动议，丹科·杰夫托维克进行了附议。主席发起投票，董事会采取了以下行动：

      鉴于，国际化域名 (IDN) 使互联网用户能够以自己的语言访问域名，并仍是 ICANN 工作的重要组成部分。

      鉴于，董事会认识到 IDN 变体是某些 IDN 顶级域 (TLD) 字符串的重要组成部分，并且根区中变体标签的实施必须以维护 DNS 安全性和稳定性的方式进行。

      鉴于，董事会在 2010 年决定在相关工作完成之前不会授权 IDN 变体 TLD，并指示 ICANN 组织制定报告，确定包含变体字符 IDN 的通用顶级域 (gTLD) 的评估、可能的授权、分配和运营需要采取哪些措施，以便促进制定可行的方法来部署包含变体字符 IDN 的 gTLD。

      鉴于 ICANN 组织和社群根据 2012 年纳入“与 IDN 变体 TLD 管理相关的问题研究”的六个案例研究，确定了两个需要解决的问题：其一，缺乏 IDN 变体 TLD 的定义；其二，缺乏 IDN 变体 TLD 管理机制。

      鉴于社群已制定涉及国际化域名应用标签的根区标签生成规则制定和维护规程（RZ-LGR 规程）来定义 IDN 变体 TLD，并且在 2013 年董事会发布批准 RZ-LGR 规程的决议之后，该规程已得到实施，以逐步制定根区标签生成规则，从而解决第一个问题。

      鉴于 ICANN 组织已制定关于管理 IDN 变体 TLD 的建议（简称变体 TLD 建议，是在纳入公众意见反馈后最终确定的六份文件合集），并将其作为解决社群在实施 IDN 变体 TLD 过程中确定的第二个问题的机制。

      兹此发布第 2019.03.14.08 号决议：董事会批准变体 TLD 建议，并要求 ccNSO 和 GNSO 在制定各自的政策时考虑变体 TLD 建议，以定义和管理当前 TLD 以及未来 TLD 申请的 IDN 变体 TLD。

      第 2019.03.14.09 号决议：董事会要求 ccNSO 和 GNSO 互通信息，告知对方各自在制定政策和程序时相关细节的进展，以确保根据变体 TLD 建议为 IDN 变体 ccTLD 和 IDN 变体 gTLD 制定一致的解决方案。

      第 2019.03.14.10 号决议：董事会还认可社群自 2011 年 IDN 变体问题项目启动以来付出的巨大努力和贡献，这促成了变体 TLD 建议的制定。

      出席会议的所有董事会成员一致投票赞成第 2019.03.14.08、2019.03.14.09 和 2019.03.14.10 号决议。决议通过。

      第 2019.03.14.08 – 2019.03.14.10 号决议的理由

      国际化域名 (IDN) 使世界各地的人们能够使用本地语言和文字的域名。一些语言文字社群已确定，严格意义上的不同域名标签可能被认为与其他域名标签无法区分，因此这些“相同”的标签被称为变体标签。国际化域名应用 (IDNA) 2008 标准不仅规定了如何使用多种文字的域名，还在 RFC 58941 中要求“注册管理机构应根据需要制定和应用其他限制以减少混淆和其他问题…。对于许多文字，使用变体技术…可能有助于减少用户可能遇到的问题。…总体而言，如果注册管理机构仅允许使用注册管理机构或其顾问充分理解的文字中的字符，将会使用户受益。”

      根据 IDNA2008 标准，必须最低限度地标识变体标签，并对其进行管理，以确保最终用户免受任何安全威胁。少数已标识的变体标签甚至可以激活以促进 IDN 的可用性，因为使用同一种文字的不同语言社群可能会使用不同的变体标签。在某些情况下，IDN ccTLD 和新 gTLD 申请已标识被视为变体标签的其他标签，表明社群可将这些不同的标签视为各自的变体。但是，由于缺乏明确的定义和实施方案，ICANN 董事会于 2010 年 9 月 25 日发布决议：“在制定适当的变体字管理解决方案前，gTLD 的任何变体均不得通过新 gTLD 项目获得授权。”该决议进一步指示 ICANN 工作人员“制定一份问题报告，确定需要在新 gTLD 流程中对包含变体字符的 gTLD 的评估、可能授权、分配及授权、分配及运营所做的工作，以促进制定部署包含变体字符 IDN 的 gTLD 的可行方法。”

      以稳定的方式实现这些安全性和可用性目标是需要解决的关键挑战。为解决这些复杂的语言和技术问题，ICANN 组织在 ICANN 董事会的指导下开展了 IDN 变体问题项目。作为第一步，它与来自六个语言文字社群的专家进行了交流，这些专家为每种文字分析了标识变体标签的问题。2011 年针对阿拉伯文、中文、西里尔文、梵文、希腊文和拉丁文文字的问题分析已纳入了问题整合报告 (IIR)（2012 年），其中确定了两个挑战：

      1. “在目前的 DNS 环境中，对于可能构成顶级标签之间变体关系的要素，缺乏公认的定义”
      2. “同时还缺乏适用于顶级的‘变体管理’机制，尽管这种机制通常被提议作为促进制定特定问题解决方案的一种方式。”

      1.定义变体 TLD

      IIR 概述了可能采取的后续工作。为解决 IIR 中提到的第一个问题，社群制定了涉及国际化域名应用标签的根区标签生成规则制定和维护规程（RZ-LGR 规程）。根据 ICANN 董事会 2013 年 4 月 11 日的指示，ICANN 采用两步流程实施了 RZ-LGR 规程，要求每个社群制定单独的基于文字的标签生成规则 (LGR) 提案，并要求一个专家小组审核各个提案，将其整合到根区 LGR (RZ-LGR)。多个语言文字社群已完成其提案，其中阿拉伯文、埃塞俄比亚语、格鲁吉亚文、高棉语、老挝语和泰国语文字提案已被整合到第二版本的 RZ-LGR，即 RZ-LGR-2。许多其他语言文字社群也在积极定义其规则。此外，还通过 IETF 制定并发布了将这些语言细节编码为正式机读格式的规范，作为标准跟踪 RFC 7940：使用 XML 表示标签生成规则。另外还开发了 LGR 工具来创建、使用和管理 LGR，该工具已向社群在线提供，并可使用开源许可下载。

      2.分析变体 TLD 管理机制

      从上述流程获得的根区标签生成规将产生可供分配的变体 TLD 标签。为了解决问题整合报告中的第二部分需求，即针对顶层制定变体管理机制，ICANN 社群有必要制定管理变体名称分配的政策和程序。这套文件已在征询公众意见后定稿并已发布，其中提供了相关建议，供 ccNSO 和 GNSO 在根据各自的政策制定流程 (PDP) 制定相关政策和程序时考虑。这些文档还分析了这些建议及其对《新 gTLD 申请人指导手册》中所述的 gTLD 申请流程的影响，并根据 IDN ccTLD 快速通道流程的最终执行计划分析了这些建议对 IDN ccTLD 申请流程的影响。提交的建议和分析的基本前提主要来自问题整合报告中的社群观察结果以及安全与稳定咨询委员会 (SSAC) 在其 SAC 60 报告中提出的建议。

      在分析过程中，ICANN 组织团队自 2014 年以来与 ICANN 董事会 IDN 工作组 (BIWG) 进行了多次交流，BIWG 指导了这项工作的完成。这些建议具有保守性，因为这是首次实施 IDN 变体 TLD，该解决方案可以根据之后的实施情况再做调整。

      ICANN 董事会指出，RZ-LGR 工作正在顺利进行。ICANN 董事会还指出，ccNSO 和 GNSO 在制定相关政策和程序的工作中可以进一步考虑以保守且一致的方式实施 IDN 变体 TLD 的初步建议。根据社群在问题整合报告中确定的先决条件，支持组织 (SO) 现在可采取后续措施。

      这将对社群产生积极影响，尽管存在一些相关风险。最低程度的要求是，标识的 IDN 变体 TLD 将被禁止申请，这将有助于最终用户的安全，直到支持组织制定出可行的管理机制。此外，如果 ccNSO 和 GNSO 能就关于授权其中一些变体标签的管理机制达成一致，则有助于在需要这些 IDN 变体 TLD 的社群促进域名的可用性。这项工作存在相关风险，特别是当社群未就 TLD 的实施方法达成一致时，因为这可能会使最终用户感到混淆，或者在其他情况下可能会给他们带来安全问题。如 SSAC 在其 SAC060 报告中所述，IDN 变体 TLD 还可能对注册人造成管理负担。根据决议，ccNSO 和 GNSO 将需要考虑所提供的建议，制定自己的政策和程序，以实施 IDN 变体 TLD。但是，该决议并未指示 ccNSO 或 GNSO 就此主题开展政策工作。如果通过适当 PDP 制定的包含政策建议的相应最终报告提交给 ICANN 董事会批准，董事会将考虑这些政策和程序如何有效地解决变体 TLD 建议及其影响和相关风险。届时，董事会将决定是否采纳政策建议并推进实施 IDN 变体 TLD。

      最终会产生财务影响。财务影响的程度取决于最终的 IDN 变体 TLD 申请评估流程以及社群建议的此申请流程的时间安排。因此，当 ccNSO 和 GNSO 最终确定实施 IDN 变体 TLD 的政策和程序并将其提交给 ICANN 董事会审议时，需要对此影响进行衡量。

      这些建议有助于确保独特标识符系统的安全和稳定运行，同时满足社群标识 IDN 变体 TLD 的需求并尊重社群的政策制定角色。针对 IDN 变体 TLD 的工作还通过增强以不同文字和语言访问互联网域名系统 (DNS) 来促进公共利益。

    2. 准备实施新 gTLD 的后续程序

      董事会财务委员会 (BFC) 主席罗恩·达席尔瓦介绍了该议程事项。罗恩解释说，BFC 已要求将该项目从议程中删除，因为虽然 ICANN 组织已完成初步规划，但 BFC 希望对总体成本和筹资模式进行进一步评估。虽然 ICANN 组织在制定项目实施规划方面取得了重大进展，但 BFC 已要求组织提供更全面的规划和相关预测，以供 BFC 及其后董事会在不久的将来进一步审议。

      经讨论后，主席宣布将该项目从议程中删除。

    3. 将 .VU（瓦努阿图）顶级域转让给电信无线电通信和广播监管机构 (TRBR)。

      克里斯·狄思潘介绍了此议程事项。克里斯解释说，ccNSO 需要填补 IANA 域名职能审核小组的三个席位，其中一个席位必须为非 ccNSO 成员。ccNSO 在填补席位上存在困难。有许多可能的解决方案可以解决这一问题，但是，在确定可行的最佳解决方案之前，该议程项目尚未准备好供董事会审议。该项目将在适当时提交董事会，以便在下次有机会时进行审议。

      尼戈尔·罗伯茨提出了动议，克里斯进行了附议。主席发起投票，董事会采取了以下行动：

      兹此发布第 2019.03.14.11 号决议：在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时，PTI 审核并评估了将 .VU 国家和地区顶级域转让给电信无线电通信和广播监管机构 (TRBR) 的请求。相关文件证明，在评估该请求时遵循了适当的程序。

      出席会议的所有董事会成员一致投票赞成第 2019.03.14.11 号决议。决议通过。

      第 2019.03.14.11 号决议的理由

      为什么董事会现在要解决此问题？

      根据《IANA 域名职能合同》的要求，PTI 已评估一项 ccTLD 转让申请，且目前正向董事会提交报告供其审核。提请董事会审核的目的是确保严格遵守相应流程。

      正在考虑的提案是什么？

      提案计划批准国家和地区顶级域 .VU 的转让申请，并向电信无线电通信和广播监管机构 (TRBR) 授予管理机构角色。

      咨询了哪些利益相关方或其他方？

      在评估此转让申请的过程中，PTI 咨询了申请人和其他重要利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商，并阐述其在本地互联网社群中的适用性。

      社群提出了哪些疑虑或问题？

      PTI 未收到社群就此申请提出的重大问题或疑虑。

      董事会审核了哪些重要材料？

      [已删除 — 敏感授权信息]

      董事会认为至关重要的因素有哪些？

      董事会未发现此申请存在任何特定隐患。

      是否会对社群产生积极或者消极影响？

      及时批准符合各种公众利益标准的国家和地区域名管理机构对 ICANN 的整体工作会有积极影响，对此类国家和地区顶级域所服务的当地社群也会有积极作用，同时还可体现积极履行 IANA 域名职能合同中所述的职责。

      是否会在财务方面对 ICANN（战略规划、运营规划、预算）、社群和/或公众产生影响或不良后果？

      管理 DNS 根区中的国家或地区代码授权是 IANA 的职责，授权行动不会对预先计划的开支有任何重大影响。评估国家和地区顶级域在特定国家或地区内部所产生的财务影响并不是 ICANN 的职责。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题？

      ICANN 认为此申请不会对安全、稳定或弹性造成明显不利影响。这属于组织管理职能，无需征询公众意见。

    4. 对重审请求 16-5：DotMusic Limited 的考量

      董事会问责机制委员会 (BAMC) 主席里昂·桑切斯介绍了此议程事项。里昂指出， BAMC 已仔细考虑了请求 16-5 的益处和所有相关材料，并建议否决请求 16-5，因为社群优先评估 (CPE) 提供商在开展 CPE 时未违反任何既定的政策或程序，并且 ICANN 组织在认可 CPE 报告时遵守了既定政策、章程和企业设立章程。BAMC 建议董事会否决请求 16-5 的原因还在于，请求者未确定 CPE 提供商存在对请求者产生重大或不利影响的误用政策或程序的情况。因此，决议是董事会采纳 BAMC 关于请求 16-5 的建议。作为此事项的审议工作的一部分，董事会已收到关于请求 16-5 的所有相关材料。

      贝基·伯尔表示，她将不参与对此事的审议，因为存在潜在的利益冲突。

      里昂提出了动议，哈立德·考巴阿进行了附议。主席发起投票，董事会采取了以下行动：

      鉴于 DotMusic Limited (DotMusic) 提交了基于社群的 .MUSIC 申请（简称“申请”），该申请与其他 .MUSIC 申请一起被归入一个字符争用集。

      鉴于 DotMusic 参加了社群优先评估 (CPE)，但并未通过 CPE。

      鉴于 DotMusic、国际音乐家联合会、国际艺术委员会和文化机构联合会、全球独立网络、Merlin Network、独立音乐公司协会、美国独立音乐协会、独立音乐协会、内容创作者联盟、纳什维尔国际歌曲作者协会和 ReverbNation（统称为“请求者”）提交了重审请求 16-5，要求重新考虑申请的 CPE 报告，以及 ICANN 组织对该 CPE 报告的认可。

      鉴于请求 16-5 尚未得出结果，董事会指示 ICANN 组织对 CPE 流程进行审核（下称“CPE 流程审核”）。董事会治理委员会 (BGC) 裁定，在 CPE 流程审核完成之前，将暂停处理有关 CPE 流程的未决重审请求（包括请求 16-5）2。

      鉴于 2017 年 12 月 13 日，ICANN 发布了三份有关 CPE 流程审核的报告（下称“CPE 流程审核报告”）。

      鉴于 2018 年 3 月 15 日，董事会通过第 2018.03.15.08 至 2018.03.15.11 号决议，在这些决议中，董事会承认并接受 CPE 流程审核报告给出的结论；声称 CPE 流程审核已完成；得出结论称，根据 CPE 流程审核报告中的结果，在当前轮次的新 gTLD 项目中，将不会更改或彻底改革 CPE 流程；并指示董事会问责机制委员会 (BAMC) 继续考虑在 CPE 流程审核完成前被暂停处理的与 CPE 流程有关的剩余重审请求。

      鉴于根据第 2018.03.15.08 至 2018.03.15.11 号决议，BAMC 邀请请求者提交更多材料并向 BAMC 进行展示，以支持请求 16-5；请求者拒绝了 BAMC 的这两个邀请。

      鉴于 BAMC 已仔细考虑了请求 16-5 的益处和所有相关材料，并建议否决请求 16-5，因为 CPE 提供商在开展 CPE 时未违反任何既定的政策或程序，并且 ICANN 组织在认可 CPE 报告时遵守了既定政策、章程和企业设立章程。BAMC 建议董事会否决请求 16-5 的原因还在于，请求者未确定 CPE 提供商存在对请求者产生重大或不利影响的误用政策或程序的情况。

      鉴于董事会已仔细审议 BAMC 就请求 16-5 提出的建议和所有与请求 16-5 相关的材料，包括请求者的反驳意见，并表示同意 BAMC 的建议，进而得出结论：反驳意见未提供支持重审的其他论据或证据。

      兹此发布第 2019.03.14.12 号决议：董事会采纳 BAMC 关于请求 16-5 的建议。

      十五位董事投票支持第 2019.03.14.12 号决议。贝基·伯尔弃权。决议通过。

      第 2019.03.14.12 号决议的理由

      1. 简要概述和建议

        完整的事实背景参见 BAMC 关于请求 16-5 的建议（下称“BAMC 建议”），董事会审核并考量了该建议，并将其纳入了此决议。

        2018 年 1 月 25 日，BAMC 评估了请求 16-5 和所有相关材料，并建议董事会否决请求 16-5，因为 CPE 提供商在开展 CPE 时未违反任何既定的政策或程序，并且 ICANN 组织在认可 CPE 报告时遵守了既定政策、章程和企业设立章程。BAMC 建议董事会否决请求 16-5 的原因还在于，请求者未确定 CPE 提供商存在对请求者产生重大或不利影响的误用政策或程序的情况。

        董事会仔细考虑了 BAMC 的建议以及与请求 16-5 有关的所有相关材料，董事会同意 BAMC 的建议。

        2019 年 2 月 12 日，请求者提交了针对 BAMC 建议的反驳意见（下称“反驳意见”）。董事会指出，适用于请求 16-5 的章程部分并未要求提供反驳意见3。但董事会已经考虑了请求者反驳意见中提出的论据，并认为这些论据无法支持重审，具体原因如下所述。

      2. 问题

        问题如下：

        • 独立审核流程 (IRP) 小组在 Little Birch LLC 等人诉 ICANN 和 Despegar Online SRL 等人诉 ICANN (Despegar IRP) 案例中的声明是否要求董事会重审 CPE 报告；
        • 董事会对于 ICANN 政府咨询委员会 (GAC) 第 1 类和第 2 类建议的认可是否要求 CPE 提供商授予该申请社群优先权；
        • CPE 提供商是否与申请存在利益冲突；
        • ICANN 组织是否对 CPE 报告进行了任何修订，如果是，这些修订是否符合既定政策或程序；
        • CPE 提供商在应用 CPE 标准 1：社群设立基础时是否遵守适用的政策和程序；
        • CPE 提供商在应用 CPE 子标准 2-A-Nexus（联系性）时是否遵守适用的政策和程序；以及
        • CPE 提供商在应用 CPE 子标准 4-A-Support（支持）时是否遵守适用的政策和程序。

        将根据适用于重审请求且在提交请求 16-5 时生效的相关标准考虑这些问题。这些标准在 BAMC 建议中进行了详细讨论并已纳入此处。

      3. 分析和理由

        1. CPE 标准和程序

          CPE 是一个争用解决机制，面向将其申请自行指定为社群申请的申请人提供4。CPE 标准和 CPE 流程在《申请人指导手册》（《指导手册》）的第 4 单元第 4.2 节中定义。接受 CPE 的社群申请通过以下标准进行评估：标准 1：社群设立基础；标准 2：提议的字符串与社群之间的联系；标准 3：注册政策；以及标准 4：社群支持5。根据《指导手册》，标准的顺序反映了 CPE 提供商评估这些标准的顺序。要通过 CPE，申请必须在这四个标准的评分中至少获得 14 分（总分为 16 分），每个标准最高得分为四分。通过 CPE 的申请将“消除所有与之直接竞争的标准申请，无论后者的合格程度如何”6。CPE 由 CPE 提供商指定的两名评估人组成的独立小组执行7。CPE 提供商的职责是确定社群申请是否满足《指导手册》第 4.2.3 节中规定的四个社群优先标准8。

          CPE 流程不确定社群的存在、充分性或有效性。它仅评估社群申请是否满足 CPE 的社群优先标准。正如《指导手册》所述：“[CPE 提供商]发现申请未达到通过社群优先评估的评分阈值并不一定表明社群自身在某方面不够资格或无效。”9

        2. Despegar IRP 声明不能为重审提供支持。

          请求者声称重审是合适的，因为 CPE 流程据称存在根本缺陷。为提供佐证，请求者援引了 Despegar IRP 声明，并认为该声明指出了 IRP 专家组对于 CPE 流程提出的问题和担忧10。请求者认为 Despegar IRP 专家组表达的担忧表明 CPE 提供商和 ICANN 组织违反了与评估申请相关的既定政策和程序11。Despegar IRP 专家组建议为未来的新 gTLD 轮次制定一个系统，以确保 CPE 评估“在一致和可预测的基础上由不同的独立评估人进行”，并确保“[CPE 提供商]等实体……贯彻 ICANN 组织的核心价值”12。请求者似乎坚称，Despegar IRP 声明要求董事会要么对 CPE 流程进行整体审核 — 董事会在 CPE 流程审核中已完成该工作 — 要么根据声称的缺陷拒绝 CPE 报告13。

          但是，BAMC 已认定并且董事会也已同意，无论是 Despegar IRP 声明本身还是 ICANN 组织对该声明的接受都没有作此要求。在接受 Despegar IRP 声明（2016 年决议）14时，董事会“注意到了 [IRP] 专家组的建议”并指示 ICANN 组织“确保新 gTLD 项目审核考虑到专家组提出的问题，因为这些问题与 CPE 流程和第三方提供商评估的一致性和可预测性有关”15。另外，CPE 流程审核还对 CPE 流程进行了额外的仔细审核，特别考虑了 ICANN 组织与 CPE 提供商的关系16。

          Despegar IRP 声明或董事会对其的接受均未要求针对申请修改 CPE 流程17，亦未要求针对质疑 CPE 报告的重审请求更改其审核标准。因此，除了确定 ICANN 组织和 CPE 提供商是否遵循了与 CPE 报告相关的既定政策和程序之外，Despegar IRP 声明或 2016 年决议均未要求董事会对该报告采取任何行动。请求者未发现违反与 CPE 报告相关的既定政策或程序的情况，下文将对此进行进一步讨论。

          此外，对于请求者认为 Despegar IRP 声明要求董事会对 CPE 流程进行整体审核，如上所述，董事会确实已进行了此类审核，即 CPE 流程审核。DotMusic 在请求 18-5 18中质疑 CPE 流程审核的结果，该请求被董事会否决19。对于董事会根据 Despegar IRP 声明或任何相关回复拒绝推翻 CPE 报告，请求者未发现存在未能考虑任何重要信息或将任何虚假或误导性信息作为依据的情况。

        3. 董事会对 GAC 第 1 类和第 2 类建议的接受与 DotMusic 对社群优先的要求无关。

          请求者声称，ICANN 组织应对申请给予“优待”，以响应 GAC 的第 1 类和第 2 类建议20。GAC 的第 1 类建议指出某些类型的字符串应接受额外的保护措施。这些类型的字符串包括：(a) 涉及受监管行业的字符串；(b) 引起消费者保护问题的字符串；(c) 其他敏感字符串。.MUSIC 是受 GAC 第 1 类建议约束的新 gTLD 之一，因为该字符串会引发消费者保护问题，即知识产权问题21。GAC 的第 2 类建议指出，表示通用术语的字符串（通用术语字符串）不应作为独家使用注册管理机构运营，除非这样做“符合公共利益目标”22。.MUSIC 也是受 GAC 第 2 类建议约束的通用术语字符串之一。

          BAMC 确定并且董事会同意，董事会对 GAC 第 1 类和第 2 类建议的接受和回应均未要求 ICANN 组织对 .MUSIC 相关社群申请给予“优待”23。GAC 第 1 类和第 2 类建议甚至没有对比讨论社群申请与标准申请。此外，与请求者声称的相反，.MUSIC 字符串之所以受第 1 类建议的约束，是因为它引起了知识产权问题，而不是因为它涉及受监管行业24。因此，GAC 的第 1 类建议没有暗示 .MUSIC 涉及请求者提出的具有“凝聚力”的社群25。关于第 2 类建议，GAC 声明，.MUSIC 之类的通用术语字符串代表了不适合注册管理机构独家使用的通用术语。GAC 的建议和 ICANN 组织对第 2 类建议的接受与社群优先无关。因此，董事会同意 BAMC 的结论，即请求者的论据无法支持重审。

        4. 通用名称支持组织 (GNSO) 建议中的内容未要求“不加深究地接受”社群优先主张。

          请求者声称根本不应该要求进行 CPE，因为 ICANN 组织的 GNSO 建议应该“不加深究地接受”申请中代表社群的主张26。请求者误解了 GNSO 实施指南的措词，这些指南并非 GNSO 的政策建议，并且要求进行某些类型的 CPE。具体而言，GNSO 指出：

          如果申请人声明 TLD 计划旨在支持特定社群，如商业性 TLD 或任何其他计划用于特定社群的 TLD，该声明将被采用而不加深究，但以下情况除外：

          (i) 声明与还服从于另一个申请的字符串相关，以及支持社群的声明正被用于获得申请的优先级；以及

          (ii) 启动了正式异议流程27。

          相应地，《指导手册》规定：“只有在导致社群优先评估的字符串争用情况下，才会评估申请人指定为基于社群的申请。”28。社群申请的申请人必须选择接受 CPE，即使并未对此作出要求。此类申请人之所以选择接受 CPE，是因为只有通过这种方式，他们才能相比于相同字符串的其他竞争性申请获得优先权29。因此，没有既定的政策或程序要求 ICANN 组织以“不加深究”的方式接受 DotMusic 的社群优先主张。因此，ICANN 拒绝“不加深究”地接受 DotMusic 的社群优先主张并没有违反任何政策或程序。

        5. 请求者未证明 CPE 提供商存在任何利益冲突。

          请求者认为 CPE 提供商与申请存在利益冲突，因为 2001 年至 2017 年担任 Google 执行总裁的埃里克·施密特 (Eric Schmidt) 在 2013 年 11 月至 2015 年 12 月期间是 CPE 提供商母公司 Economist Group 的董事会成员30，自 2003 年起担任 Google 副总裁的温特·瑟夫 (Vint Cerf)“在 2013 年（当时正在评估申请）担任了 ICANN 战略专家组的主席”，并且 Google 也提交了 .MUSIC 申请31。董事会同意 BAMC 的意见，即该论据无法支持重审，原因如下：

          首先，请求者未提供证据表明 CPE 提供商未能按照《指导手册》、CPE 专家组流程文件和 CPE 指南的要求，确认评估专家组成员或核心团队成员均与社群申请无任何冲突32。请求者并未声称高管埃里克·施密特是评估专家组成员或核心团队成员（实际上他也不是），也未声称他对 CPE 报告施加了任何影响或了解该报告（甚或与 CPE 提供商有任何关联，该提供商是 Economist Group 内的一个部门）。事实上，CPE 报告是在施密特先生不再担任 Economist Group 董事会成员之后两个月发布的33。同样，DotMusic 也没有解释温特·瑟夫 2013 年（即 CPE 报告发布的三年前）任职于关于互联网治理生态系统的 ICANN 战略专家组34对申请有任何影响。

          其次，请求者的偏见论据的唯一依据是，他们认为（基于 22 个 CPE 报告的样本集）与 Google 竞争的社群申请更有可能无法通过 CPE 35。但许多申请未能通过 CPE 的事实并不能证明存在任何程序违规。通过 CPE 的任何申请都将获得相比于所有其他申请的优先权，因此，CPE 流程特意设置了很高的通过标准36。因此，大量申请未能通过 CPE 并不能证明 CPE 提供商未遵循既定的程序和政策，以确保 CPE 提供商的成员与申请没有冲突37。此外，DotMusic 的论据所依据的 CoE 报告的结论是：“没有证据表明 Google 以任何方式影响了对 CPE 做出的决策。”38

        6. ICANN 组织不参与 CPE 标准评分。

          请求者认为，Dot Registry 诉 ICANN IRP 案例中确定的 ICANN 组织与 CPE 提供商之间的某些通信（CPE 通信）表明，ICANN 组织违反既定政策和程序对 CPE 报告进行了“实质性”修改39。BAMC 的结论是，CPE 通信中没有任何内容支持请求者的观点，即 ICANN 组织修改了 CPE 提供商对 DotMusics 申请的评分，董事会也同意这一结论。CPE 流程审核的范围 1 报告确认：“没有证据表明 ICANN 组织在 CPE 提供商发布的 CPE 报告方面对 CPE 提供商施加了任何不当影响或在 CPE 流程中参与了任何不当行为”，包括在申请方面40。当 ICANN 组织向 CPE 提供商提供意见时，该意见未涉及质疑 CPE 提供商的结论（包括评分决定），而是确保 CPE 报告清晰明确并且“CPE 提供商对 CPE 报告中的每个 CPE 标准进行了充分的讨论”41。FTI 评述称：“ICANN 组织未建议 CPE 提供商在最终评分中做出更改或调整 CPE 报告中所述的理由。”42

          请求者未确定任何不允许 ICANN 组织与 CPE 提供商就 CPE 报告中的措辞进行沟通的既定政策或程序（因为不存在这些政策或程序）。CPE 通信中的任何内容也没有如请求者所说证明 CPE 提供商缺乏进行 CPE 的必要专业知识。因此，请求者未陈述这方面的重审依据。

        7. CPE 报告没有涉及正当流程权利。

          董事会同意 BAMC 的决定，即请求者声称 CPE 提供商和 ICANN 组织未“遵循正当流程”不构成重审条件43。请求者未证明 CPE 提供商未遵守《指导手册》中规定的 CPE 的既定政策和程序。

          BAMC 指出，相关章程没有提及正当流程44。实际上，请求者认为 ICANN 组织的第三方服务提供商（包括 CPE 提供商、合法权利异议专家组和字符串混淆专家组）的决策应该有正式的上诉流程。《指导手册》中规定了在 gTLD 争用解决流程中质疑决策的方法，该指导手册是在与各种利益相关方团体（包括政府、个人、公民社会、企业和知识产权选区以及技术社群）进行多年广泛讨论后制定的45。《指导手册》已发布了多个草案版本供公众评议，并根据有意义的社群意见进行了修订46。质疑《指导手册》的时间早已过去47。

          此外，《指导手册》提供了质疑 CPE 流程结果的途径：《指导手册》第 6 单元规定，申请人（包括 DotMusic）“可以利用《ICANN 章程》中规定的任何问责机制，质疑 ICANN 就申请做出的任何最终决定”48。申请人已通过反复启用重审流程49行使了这一权利，包括针对请求 16-5 提出的重审。

          由于 CPE 提供商对申请应用 CPE 标准符合《指导手册》，ICANN 组织对 CPE 报告的接受也符合适用的政策和程序，并且未涉及任何违反“正当流程”的情况。无法对评估结果的内容进行上诉也并不代表违反了任何正当流程。

        8. 请求者关于拍卖收入的主张不能为重审提供支持。

          请求者认为 ICANN 组织接受 CPE 报告是因为受到了某种财务激励的影响，即通过拍卖流程获得收入。董事会同意 BAMC 的结论，即请求者没有提供任何证据（因为不存在任何证据）来支持请求者的这一主张。此外，请求者未证明违反了任何适用的 ICANN 政策或程序。因此，这一论据无法支持重审。

        9. CPE 提供商在应用 CPE 标准时遵守了适用的政策和程序。

          请求者反对 CPE 提供商仅向申请授予 16 分中的 10 分的决定。出于 BAMC 建议附件 1 第 VI.I 条中所述的原因（详情见本文引用的参考资料），董事会同意 BAMC 的调查结果，即由于请求者未能证明 CPE 提供商在对申请评分时违反了任何既定政策或程序，因此无需重审。此外，董事会同意 BAMC 的意见，即请求者的论据与 CPE 提供商的结论存在实质性分歧，并且这不是重审的充分依据。

        10. 请求者关于 CPE 流程审核的主张无法支持重审。

          BAMC 裁定且董事会同意，请求者关于 CPE 流程审核的主张无法支持重审，BAMC 建议附件 1 的第 VI.K 条中详细说明了所有原因（详情见本文引用的参考资料）。具体而言，董事会认为，请求者对 CPE 流程审核结论的批评无法支持重审。董事会进一步指出其在关于重审请求 18-5 的行动中阐述了许多请求者关注的问题（详情见本文引用的参考资料）。

          董事会还同意 BAMC 的结论，即请求者 DotMusic 50 要求 ICANN 组织披露与 CPE 流程审核相关的所有文件并非任何既定政策或程序的要求。此外，董事会此前在其关于重审请求 18-1 的行动中回应了 DotMusic 对前述文件的要求（详情见本文引用的参考资料）。董事会还同意 BAMC 的结论，即没有既定的政策或程序要求 ICANN 组织承担 DotMusic 审核 ICANN 组织制作的任何文件并准备向 BAMC 提交有关这些文件的补充材料而产生的费用和开支。董事会进一步同意 BAMC 的意见，即没有既定的政策或程序要求 ICANN 组织在 DotMusic 提交补充材料后向 DotMusic 提供有关请求 16-5 的具体问题列表，并安排当面陈述以解决这些问题（达到上述条件后）51。

        11. 反驳意见未提供支持重审的论据或事实。

          首先，请求 16-5 是根据 2016 年 2 月 11 日的章程提交的（参见上文的讨论），其中并未要求对 BAMC 的建议进行反驳52。尽管如此，董事会已仔细考虑请求者的反驳意见，并认为请求者未提供任何其他支持重审的论据或事实。

          1. 请求者关于社群定义的论据无法支持重审。

            请求者声称 CPE 提供商误用了关于社群设立基础的评估标准（标准 1），因为它依赖于 DotMusic 申请对于问题 20D 的回答中所定义的社群。请求者认为，《指导手册》要求 CPE 提供商完全依赖于 DotMusic 对问题 20A 的回答中所述的社群定义53。作为佐证，请求者引用了《指导手册》第 2 单元附件 2 中的图表，其中解释了新 gTLD 申请的评估问题、标准、评分和评估方法54。问题 20A 图表“问题”栏的解释称：

            提供申请人所服务社群的名称和完整描述。如果该申请参加社群优先评估，将会根据申请人在回答此问题时指出的社群进行评分。社群名称经过正式认可并非申请被指定为社群申请的必要条件55。

            请求者认为，这种解释要求 CPE 提供商应用 DotMusic 对问题 20A 的回答中提出的社群定义。董事会认为，这一论据忽略了问题 20A 的“标准”栏中所述的解释，即：

            如果申请成功，问题 20 的回答将被视为对指定社群的确定承诺，并在注册管理机构协议中体现。对问题的回答在初步评估时不计入评分。如果适用的话，可能会在社群优先评估中将此问题的回答计入评分。《申请人指导手册》的第 4 单元介绍了社群优先评估的标准和评分方法56。

            《指导手册》第 4 单元中的任何内容都未要求 CPE 提供商在评估标准 1 时仅考虑 DotMusic 对问题 20A 的回答，而不审查申请的其他部分57。因此，董事会认为此论据无法支持重审，因为请求者未证明 CPE 提供商对标准 1 的评估不符合《指导手册》或任何其他既定政策和程序。

            其次，DotMusic 认为 CPE 提供商使用了错误的社群定义，因为 CPE 提供商“未在其 CPE 中明确提及请求者的社群定义”，而是“自行创建了衍生自问题 20D 的对于社群的‘一般定义’”58。在回答问题 20A（“申请人所服务社群的名称和完整描述”）时，DotMusic 称社群的名称是“音乐社群”并对其进行了描述。在描述该社群时，DotMusic 表示：“音乐社群使用既定的 NAICS 代码严格划分……并按照以下划分标准进行组织”，然后列出了 CPE 提供商纳入 CPE 报告的 NAICS 代码59。因此，即使要求 CPE 提供商仅考虑 DotMusic 对问题 20A 的回答（但事实并非如此），CPE 提供商对 NAICS 代码的考虑本来也是合适的。

            第三，请求者声称 DotMusic 对问题 20D 的回答中所述的内容涉及“资格标准”，而非社群定义，因此 CPE 提供者在评估标准 1 时不应考虑此回复60。如上所述，《指导手册》没有要求这种程度的区分。此外，董事会指出，问题 20D 未提及资格标准；问题 20D 要求 DotMusic“说明所申请的 gTLD 字符串与[问题 20A] 中所指出的社群之间的关系”61。

            在回答问题 20D 时，DotMusic 称：“.MUSIC 通过代表参与音乐创作、制作和发行的所有选区，包括政府文化机构和艺术委员会以及其他参与符合 .MUSIC 使命的支持活动的补充 [SIC] 组织，从而与社群建立联系”62。DotMusic 未指出任何禁止 CPE 提供商在评估社群建立基础时考虑申请中定义的社群“代表的选民”的《指导手册》标准和适用的政策或程序。由于这一额外原因，该论据无法支持重审。

            第四，DotMusic 认为，由于它将音乐社群定义为“个人、组织和企业的有组织的社群，一个与音乐有关的具有类似性质的社群（‘社群’）的合理联盟”，CPE 提供商必须“承认 [DotMusic] 符合成员之间具有‘意识和认可’的‘合理联盟’的精确定义”63。BAMC 在其建议中回应了这一论据64，董事会在本文中提供了 BAMC 的完整理由陈述。BAMC 确定，《指导手册》指出，“社群的合理联盟”作为一个社群是“可行的”，“前提是成员之间对社群具有必要的意识和认可”65。由于 CPE 提供商未发现总体社群成员之间具有必要的意识和认可，因此其遵循《指导手册》的指示，在申请的标准 1 方面给的评分为零66。

          2. 请求者的其他论据此前已回应过，无法支持重审。

            请求者重复了其已多次提出的对 CPE 流程审核报告的批评，包括在请求 18-5 中的批评67。董事会于 2018 年 7 月 18 日回应了这些论据（详情见本文引用的参考资料）68。请求者在反驳意见中的其他论据重申了请求 16-5 中提出的论据和提交的支持材料，而 BAMC 在发布其建议时已考虑了所有这些论据和材料。

          3. 请求者对补充汇报邀请的回应。

            最后，董事会必须回应申请求者的主张，即他们从未“拒绝”BAMC 发出的提交补充材料来支持请求 16-5 的邀请。在反驳意见中，请求者表示，将其对 BAMC 邀请的回应描述为拒绝是“不准确的”69。然而，请求者当时对邀请回应的描述正是如此。2018 年 4 月 5 日，在回应 BAMC 发出的提交补充材料的邀请时，请求者写道：“DotMusic 拒绝 ICANN 试图对有关重审请求 16-5 的任何补充材料施加人为限制”，并且此后未提交任何汇报70。现在将 DotMusic 对 BAMC 的回应解释为“请求进行不受限制的书面材料提交和当面介绍”是不正确的71。

            基于上述原因，董事会认为无需重审。

            这项行动符合 ICANN 的使命和公共利益，因为它制定了一个流程，以便那些由于 ICANN 董事会或员工的行为而受到重大影响的个人或实体可以请求对董事会的行动或不作为进行重审，这对于确保 ICANN 在执行其使命时对社群负责，以便在《企业设立章程》、《章程》和其他既定程序内运营至关重要。采纳 BAMC 的建议不会对 ICANN 产生财务影响，并且不会对域名系统的安全、稳定与弹性产生负面影响。

            此项决议属于组织管理职能，无需征询公众意见。

    5. 对 .AMAZON 的考量

      克里斯·狄思潘介绍了议程项目，并解释说董事会已在 2019 年 3 月 10 日的会议上审议了此事项，并且该会议的获批决议已经公布。

      未达成任何决议。

    6. 接受提名委员会 (NomCom) 第二轮组织审核 —《最终报告和建议》

      艾芙丽·多利亚绍了此议程事项。艾芙丽解释说，她要求将该项目移至主要议程，依据是关于接受特定审核和组织审核建议的讨论以及 ICANN 组织和社群需要共同确定优先事项，并制定可持续的节奏来实施审核所得的建议。

      艾芙丽提出了动议，特里普蒂·辛哈进行了附议。主席发起投票，董事会采取了以下行动：

      鉴于提名委员会 (NomCom) 的第二次组织审核已于 2017 年 6 月根据《ICANN 章程》第 4.4 节第 4 条启动。

      鉴于，进行第二次 NomCom 审核的独立审核人编制了评估报告，该报告于 2018 年 1 月 10 日发布以进行公共协商，2018 年 3 月 27 日发布了最终报告草案以征询公众意见，并于 2018 年 6 月 5 日发布了包含二十七 (27) 项建议的最终报告。

      鉴于 NomCom 审核实施规划小组分析了独立审核人关于可行性和实用性的建议，考虑了临时预算影响，并预计了拟定优先实施时间表所需的资源。

      鉴于 NomCom 审核实施规划小组编制了可行性评估与初步实施规划 (FAIIP) 草案，并已在 ICANN63 期间提交给感兴趣的社群小组，得到了接收者的广泛支持。

      鉴于，经过定期与社群以及 2018 年和 2019 年 NomCom 进行磋商，实施规划小组于 2018 年 12 月 14 日以一致通过的方式批准了最终 FAIIP。

      鉴于董事会指出 FAIIP 批准流程未完全反映组织流程图中详述的程序，其中规定由接受审核的支持组织/咨询委员会 (SO/AC) 批准 FAIIP。这种偏差是由于 NomCom 的角色和成员结构与那些接受组织审核的 SO 和 AC 的委员会和领导层的角色和成员结构大有不同72。实施规划团队对 FAIIP 的一致支持、其成员的代表性、其工作的透明度以及其在整个工作期间（包括 ICANN63 期间）的外展工作责任，都弥补了在 SO 或 AC 的组织审核期间缺乏咨询委员会或委员会正式批准的缺陷。

      鉴于 NomCom 审核实施规划小组支持独立审核人的所有 27 项建议，同时对 27 项建议中的 4 项进行了少量修改，详见 FAIIP。

      鉴于 ICANN 董事会的组织效率委员会 (OEC) 在 2019 年 1 月 8 日的 OEC 会议期间收到了独立审核人关于其最终报告和 NomCom 审核实施规划小组关于其 FAIIP 的简报。

      鉴于 OEC 审议了最终报告、FAIIP 和公众意见，以便就如何进行第二次 NomCom 审核向董事会提出建议。OEC 建议董事会接受 NomCom 审核独立审核人的最终报告和实施规划小组的 FAIIP。OEC 还建议董事会指示 NomCom 审核实施规划小组组建一个实施工作组，如 FAIIP 所述在此决议通过后六个月内制订一份详细的实施规划，并在董事会批准上述详细实施规划后，让实施工作组监督这些建议的实施情况73。

      兹此发布第 2019.03.14.13 号决议：董事会感谢独立审核人的勤勉工作，并感谢其编写了一份旨在提高 NomCom 效率、透明度和问责制的全面最终报告。

      第 2019.03.14.14 号决议：董事会感谢 NomCom 审核工作组和 NomCom 审核实施规划小组在审核流程中的工作和支持。董事会感谢 NomCom 审核实施规划小组在制定可行性评估与初步实施规划方面所做的勤勉和富有洞见的工作，该规划已于 2018 年 12 月 14 日获得 NomCom 审核实施规划小组的一致通过。

      第 2019.03.14.15 号决议：董事会接受独立审核人的最终报告。

      第 2019.03.14.16 号决议：董事会接受 NomCom 审核实施规划小组的可行性评估与初步实施规划，但须进行适当的实施成本计算。董事会指示 ICANN 总裁兼首席执行官或其指定人员通过 OEC 支持 NomCom 审核实施规划小组制定并向董事会提交已接受建议的实施规划。董事会指示 ICANN 总裁兼首席执行官或其指定人员向董事会报告规划实施情况和任何社群意见。

      第 2019.03.14.17 号决议：为支持这一行动，董事会要求 NomCom 审核实施规划小组组建一个工作组，如 FAIIP 所述起草详细的建议实施规划。详细的实施规划应尽快提交给董事会，但不得晚于通过该决议后六个月。该实施规划应包括实际可行的实施时间表、预期成果的定义、如何通过实施来解决最终报告中确定的基本问题的说明、当前状态的衡量方式和实现预期成果的实施进度。工作组也应与 ICANN 组织合作，将各个实施步骤的预期预算影响纳入其详细的实施规划中。该实施规划应纳入分阶段方法，允许首先实现易于实施且成本最低的改进，对于那些具有更明显预算影响的项目，将在实施流程中的晚些时候解决。

      第 2019.03.14.18 号决议：董事会指示 NomCom 审核实施工作组在董事会接受详细的实施规划后监督实施流程。因实施而提出的任何预算申请应根据 ICANN 组织的年度预算编制流程提出。

      第 2019.03.14.19 号决议：董事会指示 NomCom 审核实施工作组每六个月向 OEC 提供有关实施规划进度的书面实施报告，包括但不限于实施规划中详述的衡量标准的完成进度以及所分配预算的使用情况。

      董事会出席会议的所有成员投票赞成第 2019.03.14.13、2019.03.14.14、2019.03.14.15、2019.03.14.16、2019.03.14.17、2019.03.14.18 和 2019.03.14.19 号决议。决议通过。

      第 2019.03.14.13 – 2019.03.14.19 号决议的理由

      董事会为什么要解决此问题？

      为确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其绩效，ICANN 依照其章程第 4 条第 4.4 款所述，对其支持组织 (SO)、咨询委员会 (AC)（政府咨询委员会除外）和提名委员会 (NomCom) 进行了组织审核。第二次 NomCom 审核于 2017 年 6 月启动。执行审核的独立审核人编制了最终报告，该报告已于 2018 年 6 月公布。根据对独立审核人最终报告的详细审阅，NomCom 实施规划小组编制了可行性评估及初步实施规划 (FAIIP)，并于 2018 年 12 月 14 日获得一致通过。

      采取该行动也是因为认识到 ICANN 以往在评估和实施审核流程得出的建议时采用的方法不具有可持续性，并且在对最终报告建议采取行动之前，ICANN 需要与社群就二者用于共同确定优先事项的流程进行沟通，并制定可持续的节奏来实施审核所得的建议。

      正在考虑的提案是什么？

      正在考虑的提案是：董事会接受最终报告、接受可行性评估与初步实施规划 (FAIIP)，并指示 NomCom 审核实施规划小组组建 NomCom 审核实施工作组，如 FAIIP 所述负责监督建议的实施。

      咨询了哪些利益相关方或其他方？

      在 NomCom 审核工作期间，独立审核人与 NomCom 现任和前任成员、更广泛的 ICANN 社群、ICANN 董事会和 ICANN 组织进行了 60 多次访谈，其在线调查收集了 85 项单独回复。独立审核人在整个审核期间与 NomCom 审核工作组定期举行会议，包括 ICANN61 和 ICANN62 期间的公共会议以及在 ICANN63 与社群团体举行的会议，针对评估报告进行了公共协商，并针对最终报告草案举行了网络研讨会。

      独立审核人公布了评估报告供公众协商，并公布了最终报告草案征询公众意见。公众意见论坛收到了 10 条评论，一条来自个人，九条代表组织。（参见公共评议期摘要报告）。NomCom 审核工作组还向独立审核人提供了关于评估报告初步草案、最终报告草案和最终报告的直接反馈。

      OEC 在 2019 年 1 月 8 日的 OEC 会议期间收到了独立审核人关于其最终报告和 NomCom 审核实施规划小组关于其 FAIIP 的简报。OEC 还考虑了社群对独立审核人评估报告和最终报告草案的反馈。

      社群提出了哪些疑虑或问题？

      虽然 NomCom 审核实施规划小组同意独立审核人提出的所有建议的精神，但同时也指出了对四项建议措辞的关切。NomCom 实施规划小组对这四项建议进行了语义修改，解决了这些关切。

      总体而言，针对独立审核人最终报告草案发表公众意见的人士表达了对报告中所包含的调查结果和建议的全面支持。

      此外，社群还支持实施规划小组在 ICANN63 期间向感兴趣的社群团体提交的可行性评估与初步实施规划草案。

      董事会审核了哪些重要材料？

      董事会审议了相关章程条款、独立审核人最终报告、NomCom 审核实施规划小组的 FAIIP 以及社群对独立审核人评估报告和最终报告草案的反馈意见，并考虑了 OEC 在提出此建议时考虑的因素。

      董事会认为至关重要的因素有哪些？

      董事会注意到 NomCom 审核实施规划小组和社群对独立审核人的最终报告草案和最终报告的全面支持，并已将它们与 NomCom 审核流程中收到的所有其他社群意见一同考虑。

      对于 NomCom 审核实施规划小组同意其精神但修改了其措辞的四项建议，董事会认为，提议的修改以及 FAIIP 中提供的理由对于解决独立审核人在最终报告中指出的问题而言是合适的。因此，董事会接受最终报告和 FAIIP。

      实现提议的改进是确保审核后 NomCom 能够履行章程规定的角色和职责的一个重要步骤。

      是否会对社群产生积极或者消极影响？

      这项董事会行动预计会对社群产生积极影响，因为它支持根据章程的要求，促进对 ICANN 的 SO 和 AC 进行定期审核的持续流程。此外，实施这些建议将有助于提高 NomCom 的透明度、问责制和效率。

      是否会在财务方面对 ICANN（战略规划、运营规划、预算）、社群和/或公众产生影响或不良后果？

      此项董事会行动将会产生财务影响，这些财务影响将被编入接下来的详细实施规划中，董事会日后会考虑该实施规划。详细的实施规划应概述如何将任何预算要求纳入未来的 ICANN 预算周期中。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题？

      此项董事会行动预计不会对与 DNS 有关的安全、稳定或弹性问题造成直接影响。

      这项行动是否符合 ICANN 的使命，它所服务的公共利益是什么？

      董事会的行动符合 ICANN 的使命及其根据章程第 4 款做出的承诺，即确保 ICANN 多利益相关方模型保持透明、负责并帮助提高其支持组织和咨询委员会的绩效。

      这项行动将通过帮助履行 ICANN 维护和改进其问责制和透明度的承诺来为公共利益服务。

      董事会采取行动前是否需要征询公众意见？

      独立审核人的最终报告草案已发布，以征询公众意见。最终可行性评估与初步实施规划草案已在 ICANN63 期间提交给感兴趣的社群小组。在董事会采取行动前，无需征询额外的公众意见。

    7. 关于组建 IANA 命名职能审核小组的后续步骤

      克里斯·狄思潘介绍了此议程事项。克里斯解释说，ccNSO 需要填补 IANA 域名职能审核小组的三个席位，其中一个席位必须为非 ccNSO 成员。ccNSO 在填补席位上存在困难。有许多可能的解决方案可以解决这一问题，但是，在确定可行的最佳解决方案之前，该议程项目尚未准备好供董事会审议。该项目将在适当时提交董事会，以便在下次有机会时进行审议。

      艾芙丽·多利亚重申，应尽早提交此事项供董事会审议，以遵守《ICANN 章程》中有关 IANA 域名职能审核的要求。

      经讨论后，主席指出该项目已从认可议程移至主要议程，现在相关人员要求将其从议程中完全删除。主席随后宣布将该项目从议程中删除。

      未达成任何决议。

    8. 其他事务

      1. 域名冲突分析项目 — 第一项研究

        前村昌纪介绍了此议程事项。前村昌纪提供了促使提出决议的事件背景，这些背景在“鉴于”条款中有详细说明。随后，前村昌纪将提出的决议加入到记录中。

        艾芙丽·多利亚对 SSAC 坚持不懈地解决问题以及 ICANN 首席技术官办公室成员的辛勤工作表示感谢。

        前村昌纪提出了动议，利托·伊瓦拉进行了附议。主席发起投票，董事会采取了以下行动：

        鉴于 2017 年 11 月 2 日，董事会要求 ICANN 安全与稳定咨询委员会 (SSAC) 制定一项计划供董事会批准，在其中列出域名冲突问题的研究，并详细说明多个要素。请参阅 https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#2.a。

        鉴于 SSAC 于 2018 年 9 月提交了一份拟议的域名冲突分析项目 (NCAP) 提案，其中详细说明了三项预计符合董事会 2017 年决议要求的研究。

        鉴于 2018 年 10 月，董事会技术委员会 (BTC) 要求 ICANN 组织通过首席技术官办公室 (OCTO) 对 NCAP 提案进行评估。随后，OCTO 和 SSAC 进行了讨论，向 OCTO 提供了有关该提案细节的更多信息和进一步说明。

        鉴于 OCTO 的评估指出，对域名冲突的先前研究进行调查和总结是有价值的，但是如果未来决定不继续进行研究 2 和研究 3，则可能没有必要制作数据储存库以及制定与使用该储存库相关的政策。因此，OCTO 修改了 SSAC 拟议的关于了解域名冲突现状的研究 1 的范围，以推迟数据储存库的部署和相关的政策制定。

        但是，OCTO 为 BTC 概述了一项关于了解域名冲突现状的拟议研究，其目标有三个：1) 审核此前有关域名冲突的所有工作，并编制一份摘要报告，将此前工作中的所有重要知识纳入到这项研究中去，使得新加入该主题讨论的人员能够获得一定的初步理解；2) 编制一个过往研究中所用数据的结果列表，找出缺漏（若有），并列出成功完成两项额外研究所需的额外数据；3) 提供相关信息，以便根据对此前工作的调查结果和数据的可用性确定 NCAP 是否应当继续进行研究 2 和 3。

        鉴于 BTC 考虑了 OCTO 关于了解域名冲突现状的研究提案，包括此研究和所有 3 项研究的财务影响，并于 2019 年 3 月 4 日建议董事会指示 ICANN 组织继续研究 1。

        兹此发布第 2019.03.14.20 号决议：ICANN 董事会感谢 SSAC 不辞辛苦，积极响应 2017 年 11 月的决议，为域名冲突分析项目 (NCAP) 制定了初步提案，并对该提案进行了后续修订。

        第 2019.03.14.21 号决议：董事会指示 ICANN 总裁兼首席执行官或其指定人员继续进行 ICANN 组织改进后的关于了解域名冲突现状的研究 1。

        第 2019.03.14.22 号决议：董事会指示 ICANN 总裁兼首席执行官或其指定人员在适当的预算和采购限额内确定并提供资金，并且拟议研究产生的费用不得超过[协商一致后确定的金额]。

        第 2019.03.14.23 号决议：出于谈判目的，该决议中的具体条款应按照《ICANN 章程》第 3 条第 3.5(b) 款的规定进行保密，保密期截至总裁兼首席执行官认为可以发布保密信息为止。

        出席会议的所有董事会成员一致投票赞成第 2019.03.14.20、2019.03.14.21、2019.03.14.22 和 2019.03.14.23 号决议。决议通过。

        第 2019.03.14.20 – 2019.03.14.23 号决议的理由

        当尝试对私营域名空间（例如：未授权的顶级域名或简短的不合格域名）中的域名进行解析时，却导致了对公共域名系统 (DNS) 的查询，此时即发生了域名冲突事件。当私营和公共域名空间的管理界限出现重叠时，域名解析就可能导致意外或有害后果。此类尚未授权的字符串被称为“冲突字符串”。在某些情况下，授权冲突字符串导致的意外或有害后果可能被视为“高风险”。例如，将冲突字符串归类为高风险字符串的参数包括：在根服务器查询中出现的频率较高、冲突字符串影响的严重程度、DNS 请求的类型、导致冲突的用户类型（例如，紧急服务和航空管制员等）、查询源的多样性，以及在内部名称证书中出现的次数。

        董事会此前已就域名冲突问题采取行动，特别是要求安全与稳定咨询委员会 (SSAC) 确定解决董事会发现的一系列问题的研究，以帮助进一步了解 ICANN 在未来域名空间扩展时如何解决域名冲突问题。为响应董事会 2017 年 11 月 2 日的决议，SSAC 于 2018 年 9 月提交了一份拟议的域名冲突分析项目 (NCAP) 提案。该提案相继详述了三项预计符合该决议要求的研究。

        然后，董事会技术委员会 (BTC) 要求 ICANN 首席技术官办公室 (OCTO) 对 NCAP 提案进行评估。针对这一要求，OCTO 和 SSAC 之间进行了讨论，以便向 OCTO 提供有关该提案细节的更多信息和进一步说明。

        最终，OCTO 向 BTC 提交了一份评估，指出对域名冲突的先前研究进行调查和总结是有价值的，但是如果未来决定不继续进行研究 2 和研究 3，则可能没有必要制作数据储存库以及制定与使用该储存库相关的政策。因此，OCTO 修改了 SSAC 拟议的关于了解域名冲突现状的研究 1 的范围，以推迟数据储存库的部署和针对后续研究的政策制定。修改后的研究 1 有三个目标：1) 审核此前有关域名冲突的所有工作，并编制一份摘要报告，将此前工作中的所有重要知识纳入到这项研究中去，使得新加入该主题讨论的人员能够获得一定的初步理解；2) 编制一个过往研究中所用数据的结果列表，找出缺漏（若有），并列出成功完成两项额外研究所需的额外数据；3) 提供必要信息，以便根据对此前工作的调查结果和数据的可用性确定 NCAP 是否应当继续进行进一步研究。

        董事会今天采取此行动有两个原因。首先，OCTO 在 NCAP 方面的工作进度是，已经充分确定要开展的研究范围。其次，下一轮新 gTLD 的域名冲突研究结果之间存在潜在的相互依赖关系，特别是在获取有关授权公共和私有域名空间中重叠字符串的能力的更多信息方面。

        该决议预计将对互联网 DNS 的安全、稳定与弹性产生积极影响，因为它旨在收集有关这一重要技术挑战的进一步信息。这也有助于 ICANN 完成其确保互联网唯一标识符系统安全稳定运行的使命。该决议符合公众利益和 ICANN 的核心价值，即保持并增强对 DNS 的管理以及 DNS 和互联网的运营稳定性、可靠性、安全性、全球互用性、弹性和开放性。

        该决议将产生财务影响，因为执行研究预计将产生费用。它指示 ICANN 组织仅开展 ICANN 组织改进后的关于了解域名冲突现状的研究 1，并根据研究 1 的结果独立考虑和指示后续研究。该决议要求 ICANN 总裁兼首席执行官根据适当的预算实践开展此项工作。

        这属于组织管理职能，无需征询公众意见。

      随后，主席宣布会议结束。

1 国际化域名应用 (IDNA)：背景、说明和理由

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

3 参见《ICANN 章程》，2016 年 2 月 11 日，第 4 条第 2 款 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV)。

4 参见《指导手册》第 4 单元第 4.2 款，第 4-7 页 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf)。另请参见 https://newgtlds.icann.org/en/applicants/cpe。

5 同上，第 4 单元第 4.2 款，第 4-7 页 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf)。

6 同上，第 4 单元第 4.2.3 款，第 4-9 页。

7同上，第 4 单元第 4.2.2 款。

8 同上，第 4 单元第 4.2.2 和 4.2.3 款，第 4-8 和 4-9 页 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf)。

9 《指导手册》第 4 单元第 4.2.3 款，第 4-9 页。

10 请求 16-5 第 19 页，第 6 节；Despegar IRP 声明第 66-67 款 (https://www.icann.org/en/system/files/files/irp-despegar-online-et-al-final-declaration-12feb16-en.pdf)。

11 请求 16-5，第 6 节，第 19 页。

12 同上，第 147、150 款（着重部分由作者标明）。

13 请求 16-5，第 6 节，第 19 页。

14 董事会第 2016.03.10.10-11 号决议 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a)。

15 同上。

16 请参阅 https://newgtlds.icann.org/en/applicants/cpe#process-review。

17 请求 16-5，第 8 节，第 17、18 页。

18 请求 18-5，https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf。

19 董事会对请求 18-5 的行动，https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f。

20 请求 16-5，第 8 节，第 5 页。

21 参见北京公报，附录 I，第 9 页，https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf；另请参见 https://newgtlds.icann.org/en/applicants/gac-advice/cat2-safeguards。

22 同上，第 11 页。

23 请参阅 https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf。另请参阅 http://www.icann.org/en/groups/board/documents/resolutions-new-gtld- 25jun13-en.htm；另请参阅 ICANN NGPC 论文 2013-06-25-2b：北京公报中 GAC 关于适用于第 2 类字符串的保护建议的建议，简报材料 1，第25-31 页 (http://www.icann.org/en/groups/board/documents/briefing-materials-1- 25jun13-en.pdf)；http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm#1.d；另请参见 http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-item-1d- 02jul13-en.pdf，附录 I，新 gTLD 协议）。

24 请求 16-5，第 8 节，第 5 页。

25 同上；另请参见布洛姆奎斯特 (Blomqvist) 意见，第 52 段，第41 页。

26 同上，第 6 段，第 3、6 页。

27 GNSO“最终报告 － 新通用顶级域名的引入”，实施指南 IG H（着重部分由作者标明）(http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm)。

28 《指导手册》第 1.2.3.2 单元，第 1-27 页。

29 同上。

30 请求 16-5，第 6 节，第 20 页。另请参阅 DotMusic CPE 流程审核函第 28、47 页，第 26(c)、67b 段（还辩称，ICC 在 .MUSIC 和 .BAND 的社群异议程序中选择的专家组成员罗宾·雅各布 [Robin Jacob] 爵士曾在一个法律案件中代表三星，而三星是“Google 的一个身价数十亿美元的合作伙伴”，更多详细信息请参阅重审请求 16-7 第 18 页 [标记为 17] 第 8 条第 68 号，https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf）。

31 DotMusic CPE 流程审核函第 26 (c) 段，第 28 页。

32 《指导手册》第 2-33 页第 2.4.3.1 款；CPE 专家组流程文件第 2 页，https://newgtlds.icann.org/en/applicants/cpe；CPE 指南第 22 页，https://newgtlds.icann.org/en/applicants/cpe。

33 施密特先生于 2015 年 12 月左右辞职 (https://www.theguardian.com/media/2015/dec/10/economist-appoints-tessa-jowell-to-board-as-googles-eric-schmidt-departs)。CPE 报告于 2016 年 2 月 10 日发布。(https://newgtlds.icann.org/sites/default/files/tlds/music/music-cpe-1-1115-14110-en.pdf)。

34 参见战略专家组：ICANN 在互联网治理生态系统中的角色 (https://www.icann.org/en/system/files/files/report-23feb14-en.pdf)。

35 请求 16-5，第 6 节，第 20 页。

36 参阅《指导手册》第 4-9 页，第 4 单元第 4.2.3 款（“合格的社群申请消除了所有其他与之直接竞争的标准申请，无论后者的合格程度如何。对于基于社群申请资格的非常严格的要求，这就是根本原因。”）

37 请求者引用在公共论坛上与法迪·切哈德 (Fadi Chehadé) 的交流。参见 https://singapore52.icann.org/en/schedule/thu-public-forum/transcript-public-forum-12feb15-en.pdf，第61-62 页。在交流期间，切哈德先生感谢 DotMusic 的评论，并要求 DotMusic 向 ICANN 发送一封信函，解释 DotMusic 的担忧。DotMusic 从未发过这样的信函。关于此次交流的任何内容都不包含对请求者所暗示的任何利益冲突的“确认”。参见请求 16-5，第 6 节，第 20 页。

38 CoE 报告，第 47 页，引自 DotMusic CPE 流程审核信函第 28 页，第 26 (c) 条。

39 请求 16-5，第 6 节，第 18 页。

40 FTI 范畴 1 报告，第 3 页 https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf。

41同上，第 12 页。

42同上。

43 请求 16-5，第 8 节，第 16 页（标记为第 15 页）。

44 参见《ICANN 章程》，2016 年 2 月 11 日。

45 《指导手册》，前言。

46 同上。

47 参阅 https://newgtlds.icann.org/en/applicants/agb，表明指导手册的当前版本日期为 2012 年 6 月 4 日。根据 2012 年 6 月生效的章程，重审请求应在董事会行动公布后 30 天内或在请求者发现或应合理知悉受质疑的员工行动后的 30 天内到期。《ICANN 章程》，2012 年 3 月 16 日，第 IV 条，第 2.5 款 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV)。

48 《指导手册》第 6 单元第 6 款，第 6-4 页。

49 参阅请求 14-28，https://www.icann.org/en/system/files/files/request-dotmusic-07jun14-en.pdf；请求 16-7，https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf；请求 17-2，https://www.icann.org/en/system/files/files/reconsideration-17-2-dotmusic-request-redacted-18jun17-en.pdf；请求 17-4，https://www.icann.org/en/system/files/files/reconsideration-17-4-dotmusic-dotgay-request-redacted-25jul17-en.pdf；请求 18-1，https://www.icann.org/en/system/files/files/reconsideration-18-1-dotmusic-request-redacted-10mar18-en.pdf；请求 18-5，https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf。

50 董事会指出，这项主张仅由请求者 DotMusic 在支持请求 16-5 的补充材料中提出，而非其他请求者提出。参见 https://www.icann.org/en/system/files/files/reconsideration-16-3-et-al-dotgay-dechert-to-icann-board-bamc-redacted-23mar18-en.pdf。

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

52 参见《ICANN 章程》，2016 年 2 月 11 日，第 4 条第 2 款 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV)。

53 反驳意见，第3-5 页 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-requestors-rebuttal-to-bamc-recommendation-request-12feb19-en.pdf)。

54 同上；另见《指导手册》，第 2 单元，附件 2 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf)。

55 《指导手册》，第 2 单元，附件 2，第 A-14 页 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf)（着重部分由作者标明）。

56同上。（着重部分由作者标明）

57 参阅《指导手册》，第 4 单元第 4.2.3 款，第第 4-10 – 4-12 页。

58 反驳意见，第 6 页。

59申请，问题 20A (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392)。

60 反驳意见第 4 页（省略了内部引号）。

61 《指导手册》，第 2 单元附件 2，第 A-14 页。

62申请，问题 20D (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392)。

63 反驳意见，第 4-5 页。

64 参见 BAMC 建议附件 1，第 29 页 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-bamc-recommendation-attachment-1-25jan19-en.pdf)。

65 《指导手册》，第 4 单元第 4.2.3 款，第 4-12 页（着重部分由作者标明）。

66同上。

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

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

69 反驳意见，第 1 页。

70 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf（着重部分由作者标明）。

71 反驳意见，第 1 页。

72 将在审核和更新 ICANN 流程文档的标准流程中对流程图进行更新以阐明这一点。

73 董事会对详细实施规划的接受偏离了组织审核流程图，但此步骤符合组织审核的标准做法，因为董事会通过审核和接受所述详细实施规划来履行其信托责任。将在审核和更新 ICANN 流程文档的标准流程中对流程图进行更新