Skip to main content
Resources

قرارات مجلس الإدارة المعتمدة | الجلسة الافتتاحية لورشة عمل مجلس الإدارة، لوس أنجلوس | الاجتماع الاعتيادي لمجلس إدارة ICANN

هذه الصفحة متوفرة باللغات:

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到: https://www.icann.org/resources/board-material/resolutions-2019-09-08-en

  1. 认可议程
    1. 批准会议记录
    2. RSSAC 人事任命
    3. NomCom 主席及候任主席任命
    4. 批准对 RSSAC 和 SSAC 成员构成的标准章程修订
    5. 批准对 IANA 域名职能审核小组成员构成的基本章程修订
    6. ITU-D 成员确认
  2. 主要议程
    1. 将代表欧盟的希腊文域名 .ευ ("eu") 授权给 EURid vzw/asbl。
    2. 重审请求 19-1:哥伦比亚政府回复:“.AMAZON”事务
    3. GAC 建议:马拉喀什公报(2019 年 6 月)
  1. 认可议程:

    1. 批准会议记录

      第 2019.09.08.01 号决议:董事会批准 2019 年 3 月 1 日 ICANN 董事会特殊会议和 2019 年 6 月 23 日 ICANN 董事会例行会议的会议记录。

    2. RSSAC 人事任命

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

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

      鉴于 RSSAC 联合主席建议 ICANN 董事会向 RSSAC 任命来自美国国防信息系统局、美国国家航空航天局 (NASA)、美国马里兰大学和美国陆军研究实验室的代表。

      兹此发布第 2019.09.08.02 号决议:ICANN 董事会任命基斯·布鲁斯坦 (Keith Bluestein)、霍华德·卡什 (Howard Kash)、卡尔·罗伊斯 (Karl Reuss) 和凯文·莱特 (Kevin Wright) 为 RSSAC 成员,任期截止日期为 2022 年 12 月 31 日。

      第 2019.09.08.02 号决议的理由

      2013 年 5 月,根服务器运营商组织同意了向 RSSAC 任命的代表的初始成员构成,且各个组织提名了一位个人。2013 年 7 月,ICANN 董事会批准了 RSSAC 的初始成员构成,对成员实行交错任期制。来自美国国防信息系统局、美国国家航空航天局 (NASA)、美国马里兰大学和美国陆军研究实验室的代表将于 2019 年 12 月 31 日结束当前任期。

      今天,董事会正在根据《ICANN 章程》第 12 条第 12.2 (c)(ii) 款的规定采取行动,任命 RSSAC 成员。

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

      该决议属于组织管理职能,无需征询公众意见。RSSAC 成员的任命符合公共利益,并且有助于 ICANN 组织履行加强 DNS 安全、稳定与弹性的承诺。

    3. NomCom 主席及候任主席任命

      鉴于 BGC 审阅了 2020 年度提名委员会 (NomCom) 主席和候任主席候选人的意向书,考量了 2019 年度 NomCom 成员对 NomCom 领导人及表示有意担任领导职位的成员的评价,并与候选人进行了面谈。

      鉴于 BGC 建议任命杰·苏道斯基 (Jay Sudowski) 为 2020 年度 NomCom 主席,奥利·雅各布森 (Ole Jacobsen) 为 2020 年度 NomCom 候任主席。

      兹此发布第 2019.09.08.03 号决议:董事会在此任命杰·苏道斯基为 2020 年度提名委员会主席,奥利·雅各布森为 2020 年度提名委员会候任主席。

      第 2019.09.08.03 号决议的理由

      《ICANN 章程》要求董事会任命提名委员会 (NomCom) 主席和候任主席。请参阅《ICANN 章程》第 8 条第 8.1 款。董事会已授权董事会治理委员会 (BGC) 负责推荐 NomCom 主席和候任主席供董事会批准。(请参阅 BGC 章程:http://www.icann.org/en/committees/board-governance/charter.htm。)2019 年 5 月 24 日,BGC 见证发布了征求意向书 (EOI) 的公告,要求在 2019 年 6 月 15 日前提交意向书(请参阅 https://www.icann.org/news/announcement-2019-05-24-en),之后这一截止期限被延长至 2019 年 7 月 5 日 (https://www.icann.org/news/announcement-2-2019-06-14-en)。

      为指导 2020 年度 NomCom 领导职位的人员遴选工作,BGC 审阅和讨论了所收到的 EOI,了解了 NomCom 成员对 2019 年度 NomCom 领导人及表示有意担任 NomCom 领导职位的 2019 年度 NomCom 成员的评价,并与候选人进行了面谈。完成上述工作并经过进一步讨论后,BGC 就要向董事会推荐的 2020 年度 NomCom 主席和候任主席人选达成一致意见。

      董事会已考量并同意 BGC 推荐的 2020 年度 NomCom 主席和 2019 年度 NomCom 侯任主席。董事会还想感谢所有有意成为 2020 年度 NomCom 领导人并提交了意向书的人士。

      通过公开 EOI 流程选拔和任命 NomCom 主席和侯任主席(包括审核候选人)符合公共利益,因为这对 ICANN 的透明度和问责制产生了积极影响。这也完全符合 ICANN 的使命。

      采纳 BGC 的建议不会对 ICANN 产生额外的财务影响,并且不会对域名系统的安全、稳定与弹性产生负面影响。

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

    4. 批准对 RSSAC 和 SSAC 成员构成的标准章程修订

      鉴于《章程》第 12 条第 12.2(b) 款对安全与稳定咨询委员会 (SSAC) 做出了规定,第 12 条第 12.2(c) 款对根服务器系统咨询委员会 (RSSAC) 做出了规定。

      鉴于根据现行《章程》第 12 条第 12.2(b) (ii) 款,SSAC 不得限制 SSAC 主席的任期届数,SSAC 提议对该条款进行修订,删除提及主席任期的内容,这将使 SSAC 能够根据自己的意愿实行任期限制。

      鉴于根据现行《章程》第 12 条第 12.2(c)(ii) 款,RSSAC 需由两名联合主席领导,RSSAC 提议对第 12 条进行修订,将主席人数减少至一名。

      鉴于 SSAC 和 RSSAC 在实施最近组织审核所产生建议的过程中,都积极要求作出这些修订。

      鉴于 2019 年 5 月 3 日,根据《ICANN 章程》第 25.1(b) 款所述的标准章程修订流程,ICANN 董事会批准发布这些拟议章程修订以征询公众意见。

      鉴于修订内容已面向公众发布,意见征询期从 2019 年 6 月 10 日持续到 2019 年 8 月 9 日。期间共收到了两条意见,它们都支持修订。

      鉴于董事会组织效率委员会建议批准已发布征询公众意见的、与 SSAC 和 RSSAC 领导层相关的章程修订。

      兹此发布第 2019.09.08.04 号决议:根据《ICANN 章程》第 25.1 款,董事会批准已发布征询公众意见的、对第 12 条第 12.2(b)(ii) 款和第 12.2(c)(ii) 款的修订,并指示 ICANN 总裁兼首席执行官或其指定人员继续执行标准章程修订流程,完成对这些条款的修订。

      第 2019.09.08.04 号决议的理由

      董事会今天采取此行动,既是应 SSAC 和 RSSAC 的要求,也是为了支持《ICANN 章程》第 4.4 款所要求的组织审核。Analysis Group 在 SSAC 独立审核最终报告中建议,应对 SSAC 的领导层实行任期限制,而现行章程不允许这样做。在对 RSSAC 组织审核提出的继任问题相关建议的直接回应中,RSSAC 领导层结构的灵活性被作为一个实施项提出。

      这些修订内容已联合发布以征询公众意见,最终收到了两条意见。这两条意见分别来自 ICANN 企业选区和非商业利益相关方团体,均对拟议的章程修订表示支持。意见的具体内容可参阅员工报告

      今天的行动不会造成任何已知的财务影响,也不会影响互联网 DNS 的安全、稳定或弹性。此项行动通过支持对这两个关键咨询委员会的治理的持续改进,符合 ICANN 关于确保互联网唯一标识符系统稳定、安全运营的使命。另外,由于所提出的两项修订均是组织审核流程的结果,此项行动也是对该流程问责的支持。它遵循了章程规定的修订流程,符合公共利益,支持 ICANN 的多利益相关方社群,同时使得 ICANN 能够继续对其章程规定的机制负责。

      这属于组织管理职能,已为其征询了公众意见。

    5. 批准对 IANA 域名职能审核小组成员构成的基本章程修订

      鉴于《ICANN 章程》第 18 条要求 ICANN 促成对 IANA 域名职能表现的定期审核。

      鉴于 2018 年 9 月,董事会启动了首次 IANA 域名职能审核,各个任命实体开始着手组建 IANA 域名职能审核小组(IFR 小组)。

      鉴于,由于 ccNSO 的成员构成在 IANA 管理权移交之后的这些年发生了变化,ccNSO 理事会很难按照《ICANN 章程》第 18.7(b) 款的要求找到非 ccNSO 的 ccTLD 代表。结果,这大大延误了 IFR 小组组建的完成,并且预计在未来的 IANA 域名职能审核中也会出现同样的困境。

      鉴于 2019 年 4 月 12 日,ccNSO 理事会通过其主席向 ICANN 董事会发出请求,希望启动一项针对《ICANN 章程》的修订流程以解决这一困境,并提议了修订内容。

      鉴于 2019 年 5 月 31 日,在收到董事会组织效率委员会(负责协调董事会对 IANA 域名职能审核的监督)的建议后,ICANN 董事会指示 ICANN 组织发布拟议的修订内容以征询公众意见,并根据《ICANN 章程》第 25.2 款启动了基本章程修订流程。

      鉴于针对《ICANN 章程》第 18.7 款的拟议修订内容已面向公众发布,意见征询期从 2019 年 6 月 10 日持续到 8 月 9 日。期间共收到了六条意见,均未反对修订。

      鉴于 OEC 建议董事会批准已发布征询公众意见的、对《ICANN 章程》第 18.7 款的修订,并指示 ICANN 组织继续完成基本章程修订流程。

      兹此发布第 2019.09.08.05 号决议:ICANN 董事会批准已发布征询公众意见的、对《ICANN 章程》第 18.7 款的修订。董事会指示总裁兼首席执行官或其指定人员按照《ICANN 章程》第 25.2 款继续完成基本章程修订流程。

      第 2019.09.08.05 号决议的理由

      推进基本章程修订流程是对 ccNSO 理事会要求的直接回应,同时支持了社群在 IANA 管理权移交过程中新设计的问责和监督机制。IANA 域名职能审核是对 IANA 域名职能表现进行问责和监督的一个重要组成部分,也是移交提案的一个关键方面。虽然在章程修订流程进展到现在,ccNSO 理事会经过坚持不懈的努力,最终成功找到了非 ccNSO 成员的 ccTLD 经理人来加入当前的 IANA 域名职能审核小组,但若我们不继续完成这一修订流程,将来 ccNSO 理事会很可能无法满足 IANA 域名职能审核小组的成员构成要求。今天采取此项行动是向确保能够继续以 ICANN 社群共同支持的方式开展 IANA 域名职能审核迈出的重要一步,如基本章程流程中所述。

      做出此项行动是基于对 ccNSO 希望修订章程的初步请求的审核,以及对围绕拟议修订内容收到的公众意见(包括公众意见员工报告)的审核。一共收到了六条独立意见,评议者包括 ccNSO 理事会、企业选区、注册管理机构利益相关方团体、非商业利益相关方团体、一般会员咨询委员会和供职于 Nominet 公司的一位个人。其中,ccNSO、BC、RySG、ALAC 和个人评议者均支持拟议的章程修订。NCSG 虽然不反对这一建议,但表示章程中应该同时说明,理事会必须尽其最大努力去寻找非 ccNSO 成员。参与了 ccNSO 流程的个人评议者警告称,章程不应对 ccNSO 流程过于苛刻。所有评议者均不反对拟议的修订内容。对于 NCSG 提出的应该进一步修改拟议修订内容的建议,其他评议者(包括 ccNSO)均持不支持态度。

      董事会意识到,同时负责任命两名 IFR 小组成员的 RySG 在其意见中提出了一点建议,认为应该进一步修订关于成员构成的要求,放宽 RySG 对必须选择具有地理多样性的成员所负有的责任。今天就 ccNSO 提议的修订内容所采取的行动并不排除今后对章程这一条款作出进一步修订,也不构成对 RySG 建议的任何评估。董事会期待在通过开展 IFR 发现其他问题时继续与 RySG 及更广泛的社群进行对话,并将地理多样性问题与在即将实施加强 ICANN 问责制跨社群工作组第 2 工作阶段提出的多样性建议时所需的工作放在一起考量。

      今天的行动不会造成任何已知的财务影响,也不会影响互联网 DNS 的安全、稳定或弹性。此项行动将允许对 ICANN 如何履行域名职能进行持续监督,符合 ICANN 关于协调根区域名分配与指定的使命。它遵循了章程规定的修订流程,符合公共利益,支持 ICANN 的多利益相关方社群,同时使得 ICANN 能够继续对其章程规定的机制负责。

      这属于组织管理职能,已为其征询了公众意见。

    6. ITU-D 成员确认

      鉴于经董事会讨论和支持,ICANN 组织申请了加入 ITU-D(国际电联电信发展部门)成为部门成员,并且一旦获得批准,将同时寻求会费减免。

      鉴于 ICANN 与 ITU-D 的合作是基于有效参与 ITU 以及(与技术社群的其他成员一起)成为 ITU 成员的重要性,其目的在于促进关于 ICANN 所扮演角色的有效沟通,并在适当情况下捍卫我们的使命和多利益相关方流程。

      鉴于 2019 年 6 月,ICANN 被告知其部门成员申请已获得批准,同时获得了会费减免。

      兹此发布第 2019.09.08.06 号决议:董事会感谢 ITU 批准 ICANN 成为 ITU-D 部门成员,并感谢 ITU 给予会费减免。董事会指示 ICANN 总裁兼首席执行官或其指定人员在申请获得批准后,根据 ICANN 组织合作战略审核 ICANN 参与 ITU-D 的适当后续步骤。

      第 2019.09.08.06 号决议的理由

      作为技术社群的一分子,ICANN 与国际电信联盟 (ITU) 有着悠久的合作历史。过去,ITU 曾是技术联络组(TLG,现在已不复存在)的成员,负责每三年安排一名联络人到 ICANN 董事会任职。尽管 TLG 在几年前已经解散,但确保能够继续与 ITU 合作对 ICANN 仍然很重要。

      ICANN 申请成为 ITU-D 部门成员,以及该申请最终在会费减免的基础上获得批准,这些是对两个组织之间互惠关系的重要认可。成为 ITU-D 部门成员为 ICANN 组织有效沟通 ICANN 所扮演角色以及在适当情况下捍卫 ICANN 使命和多利益相关方流程提供了机会。

      由于 ICANN 与其他技术组织之间的合作有助于 ICANN 获得和加强其确保互联网唯一标识符系统稳定、安全运营的能力,此项行动符合 ICANN 的使命。此外它也符合公共利益,因为它捍卫和认可其他实体在更广泛的生态系统中发挥的作用,以及在保持沟通渠道畅通和捍卫 ICANN 多利益相关方模型方面的价值。

      此项行动预计不会对 ICANN 的资源产生影响,也不会对互联网 DNS 的安全或稳定产生直接影响。该决议属于组织管理职能,无需征询公众意见。

  2. 主要议程:

    1. 将代表欧盟的希腊文域名 .ευ ("eu") 授权给 EURid vzw/asbl。

      第 2019.09.08.07 号决议:作为履行其在与 ICANN 签订的 IANA 域名职能合同下的责任的一部分,IANA 审核并评估了将顶级域名 .ευ 授权给 EURid vsw/asbl 的申请。相关文件证明,在评估该申请时遵循了适当的程序。

      第 2019.09.08.07 号决议的理由

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

      根据 IANA 域名职能合同的要求,IANA 已评估一项 ccTLD 授权申请,目前正将报告提交董事会审核。提请董事会审核的目的是确保严格遵守相应流程。

      正在考虑的提案是什么?

      正在考虑的提案是批准申请,该申请希望创建希腊文国家和地区顶级域 .ευ 并将经理人的角色分配给 EURid vsw/asbl。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    2. 重审请求 19-1:哥伦比亚政府回复:“.AMAZON”事务

      鉴于哥伦比亚政府(简称“请求人”)提交了重审请求 19-1,要求重审 ICANN 董事会第 2019.05.15.13–2019.05.15.15 号决议(简称“2019 年 5 月 15 日决议”)。

      鉴于请求人指出董事会未考量某些实质性信息,且董事会在通过 2019 年 5 月 15 日决议时基于了不准确的信息。

      鉴于请求人进一步指出,董事会直到会议预定召开的前一天才发布 2019 年 5 月 15 日董事会会议的议程,此举违反了《ICANN 章程》的规定。

      鉴于请求人进一步指出,ICANN 组织在 ICANN65 期间安排与 ICANN 注册管理机构利益相关方团体召开了封闭会议,共同讨论修订之前已签约公共利益承诺的潜在流程,这违反了《ICANN 章程》中关于透明度的规定。

      鉴于董事会问责机制委员会 (BAMC) 之前已确定请求 19-1 的陈述充分,并根据《ICANN 章程》第 4 条第 4.2(j) 和 (k) 款将请求 19-1 送交监察官考量。

      鉴于监察官根据章程第 4 条第 4.2(l)(iii) 款的规定回避此事。

      鉴于 BAMC 仔细考虑了请求 19-1 的益处和所有相关材料,并建议否决请求 19-1,原因如下:董事会通过 2019 年 5 月 15 日决议所依据的是准确而完整的信息,且董事会和 ICANN 组织均未采取任何违反《ICANN 章程》的行动。

      鉴于根据《ICANN 章程》第 4 条第 4.2(q) 款,请求人在收到 BAMC 关于请求 19-1 的建议后有 15 天时间提交反驳意见。到截止日期 2019 年 8 月 29 日时请求人未提交反驳意见,到目前为止也未收到任何反驳意见。

      兹此发布第 2019.09.08.08 号决议:董事会采纳 BAMC 关于请求 19-1 的建议

      第 2019.09.08.08 号决议的理由

      1. 摘要和建议

        完整的事实背景参见 BAMC 关于请求 19-1 的建议(下称“BAMC 建议”),董事会审核并考量了该建议,并将其纳入了此决议。

        2019 年 8 月 14 日,BAMC 评估了请求 19-1 和所有相关材料,并建议董事会以 2019 年 5 月 15 日决议的通过所依据的是准确而完整的信息为由否决请求 19-1。BAMC 进一步建议董事会以董事会和 ICANN 组织均未采取任何违反《ICANN 章程》的行动为由否决请求 19-1。

        根据《章程》第 4 条第 4.2(q) 款,请求人在收到 BAMC 关于请求 19-1 的建议后有 15 天时间提交反驳意见。到截止日期 2019 年 8 月 29 日时请求人未提交反驳意见,到目前为止也未收到任何反驳意见。

        董事会仔细考虑了 BAMC 的建议以及与请求 19-1 有关的所有相关材料,董事会同意 BAMC 的建议

      2. 问题

        问题如下:

        • 董事会通过 2019 年 5 月 15 日决议时是否依据了错误或不准确的相关信息,或未考虑实质性信息。

        • 董事会通过 2019 年 5 月 15 日决议是否违反了《ICANN 章程》,后者规定“对于每次的董事会会议,应至少提前七天发布会议通知和已知的会议议程(若这种做法不切实际,则需尽量提前通知)。”1

        • ICANN 组织或 ICANN 董事会与注册管理机构利益相关方团体 (RySG) 召开封闭会议讨论修改公共利益承诺的潜在流程的做法是否违反了《ICANN 章程》,后者要求 ICANN 的“运作方式必须最大程度地体现公开性和透明度”。2

      3. 分析和理由

        1. 董事会在通过决议前考虑了实质性信息。

          董事会在通过 2019 年 5 月 15 日决议时确实考虑了所有相关材料。请求人指出“ICANN 工作人员和董事会 ... 未考虑 [2019 年 4 月 7 日] 致亚马逊公司的信函中提出的详细法律问题,这份信函抄送给了 ICANN 首席执行官、ICANN 董事会主席和 ICANN 的 GAC 主席。”3 与此相关的是,请求人在 2019 年 4 月 7 日致亚马逊公司的信函中指出“哥伦比亚政府提供其他治理结构”,但“ICANN 董事会在寻求让双方达成一致解决方案时,似乎甚至都没有考虑过这一潜在选项。”4 与请求人的论断相反,在 2019 年 5 月 1-3 日举行的董事会工作坊上,董事会在围绕亚马逊公司 2019 年 4 月所提方案的讨论中曾考虑了请求人 2019 年 4 月 7 日信函中提出的问题。因此,BAMC 得出结论,没有证据表明董事会在通过 2019 年 5 月 15 日决议时未考虑实质性信息,董事会同意这一结论。5

          1. 董事会考虑了请求人 2019 年 4 月 7 日信函中提出的“法律问题”。

            请求人认为董事会未考虑请求人提出的“法律问题”的结论完全基于请求人的断言,即“无法在 ICANN 公共通信网站或决议所引用的任何参考资料中找到 [2019 年 4 月 7 日] 信函。”6 然而,请求人 2019 年 4 月 7 日信函的收件人是亚马逊公司,并不是 ICANN 董事会、ICANN 组织或任何与 ICANN 相关的个人。7 ICANN 组织的总裁兼首席执行官和董事会主席仅仅是信函的抄送人而已。8 ICANN 的政策或惯例是不公开发布仅仅抄送给自己的、第三方之间的通信。

            虽然董事会承认,未在 2019 年 5 月 15 日决议理由的“董事会审核了哪些重要材料”部分明确列出请求人的 2019 年 4 月 7 日信函,但请求人 2019 年 4 月 7 日信函中提出的法律问题和拟议 .AMAZON TLD 联合治理结构在来自 ACTO 成员国的其他通信中同样有提到,而董事会在通过 2019 年 5 月 15 日决议时考虑并列出了后者。9 具体而言,提到这些法律问题和拟议联合治理结构的通信包括 ACTO 秘书长于 2019 年 4 月 11 日致 ICANN 董事会主席的信函10 以及巴西大使扎卢尔 (Zaluar) 于 2019 年 4 月 23 日11 和 2019 年 5 月 7 日12 致 ICANN 董事会的信函。此外,ACTO 在其 2019 年 4 月 11 日致董事会的信函中指出,ACTO 成员国“在过去几年已经多次表明 ... 他们在协议底线问题上的共同和明确立场,即建立 TLD 共同治理结构。”13 2019 年 5 月 15 日决议的“董事会审核了哪些重要材料”部分列出了这些信函。14

          2. 董事会考虑了请求人和 ACTO 成员国提出的替代治理模型。

            与请求人的论断相反,董事会在通过 2019 年 5 月 15 日决议时确实考虑了请求人和 ACTO 成员国提出的替代治理模型。董事会不接受拟议联合治理模型的事实并不能证明董事会未考虑这些方案。15 另外需要指出的是,替代治理模型对董事会在决定是否通过决议时考虑的问题而言并不重要。也就是说,根据 2019 年 3 月 10 决议,董事会要考虑的问题是亚马逊公司提出的方案是否可接受,而不是将亚马逊公司的方案与其他利益相关方提出的替代方案进行比较。不过,董事会确实考虑了所提出的替代治理模型。

        2. 董事会并未基于错误或不准确的信息通过 2019 年 5 月 15 日决议。

          1. ICANN 董事会在通过 2019 年 5 月 15 日决议时未批准亚马逊公司的规范 13 申请。

            请求人声称,在通过 2019 年 5 月 15 日决议时,“ICANN 董事会似乎盲目接受了亚马逊公司的陈述,即,在规范 13 指定下运营有争议的字符串既符合 ICANN 现有的既定最佳实践,又能保障所有各方的最佳利益。”16 根据请求,“事实并非如此”,因此认定此为不准确的信息,因为“只有商标所有者及其关联公司和被许可方才能使用规范 13 所定义的域名(即品牌)TLD”,而请求人“看不出亚马逊公司提出的允许 ACTO 成员国成为域名受益注册人的方案符合现有的 ICANN 注册管理机构合同框架。”17

            董事会在 2019 年 5 月 15 日决议中决定,ICANN 组织应“根据新 gTLD 项目的政策和程序”“继续处理”.AMAZON 申请,这一决定并非自动赋予亚马逊公司继续推进 .AMAZON TLD 授权的权利,董事会的行动也不构成通过对亚马逊公司规范 13 申请将此域名作为品牌 TLD 运营的批准。在通过 2019 年 5 月 15 日决议时,董事会确认,.AMAZON 申请仍需按照申请人指导手册完成剩下的申请流程。18

            虽然董事会意识到亚马逊公司打算将 .AMAZON TLD 作为品牌 TLD 来运营19,但 2019 年 5 月 15 日决议并未对任何规范 13 申请的正当性表明立场,因为单个规范 13 申请由 ICANN 组织负责评估和批准或者否决。20 董事会指出,在董事会通过 2019 年 5 月 15 日决议时,亚马逊公司尚未就拟议的 .AMAZON TLD 提交正式的规范 13 申请。由于董事会未对任何规范 13 申请的正当性表明立场,也就不存在它依赖于任何有关规范 13 的“陈述”,因此,该等陈述不支持请求人声称董事会在通过 2019 年 5 月 15 日决议时基于不准确的信息的论断。

          2. 规范 13 的状态不一定与拟议 PIC 不一致。

            请求人声称亚马逊公司的拟议 PIC 将自动与亚马逊公司提交的任何规范 13 申请不一致。董事会不赞同请求人的结论。规范 13 提出了诸多要求,包括规定仅注册管理运行机构(这里指的是亚马逊公司)及其“关联公司或商标被许可方可以成为 TLD 的域名注册人,以及在 TLD 任何层级控制与域名相关的 DNS 记录。”21 它并未禁止第三方使用品牌 TLD 中的域名,而这正是亚马逊公司所提议的。22

            请求人称,其已经在请求人 2019 年 4 月 7 日信函中告知董事会亚马逊公司规范 11 与规范 13 指定之间存在的冲突。董事会指出,请求人实际上在信函中承认,拟议 PIC 与规范 13 在本质上并不冲突。也就是说,请求人并声称拟议 PIC 实际上违反了规范 13,准确地说,请求人假定拟议 PIC“违反了规范 13 准则的精神和 ICANN 组织在批准规范 13 申请时应遵循的最佳实践。”23 由于规范 13 并未禁止亚马逊公司提出的使用类型(无第三方注册),请求人关于违反规范 13“精神”的断言是错误的,无法构成启动重审的理由。24

            最后,请求人对规范 13 的担忧似乎源于这样一种观念,即认为亚马逊公司若为拟议 .AMAZON TLD 提出规范 13 申请,一旦通过,此规范 13 状态将使 PIC 无效或减弱其影响力。25 虽然董事会理解请求人的担忧,但在现阶段,这些担忧是毫无根据的,也是为时过早的。亚马逊公司的规范 13 状态与其规范 11 PIC 并无关系。批准规范 13 成为最终注册管理机构协议以及将 TLD 指定为品牌 TLD 都不会使得注册管理运行机构的规范 11 PIC 无效。适用情况下,注册管理运行机构将同时受规范 11 承诺和规范 13 义务的约束。每份规范都有其自己的执行机制。注册管理运行机构未按规范 11 PIC 运营的,将依照公共利益承诺争议解决流程进行处理。26 类似地,若注册管理运行机构未能满足规范 13 的要求,“(i) TLD 应立即终止作为品牌 TLD;(ii) 注册管理运行机构应立即遵守 [注册管理机构] 协议的规定,该协议内容不再因规范 13 [ ] 而得到修改;以及 (iii) 规范 13 [ ] 的条款此后不再具有任何效力。”27 因此,若亚马逊公司的规范 11 与规范 13 之间存在任何实际冲突,我们也有相应的保护措施来予以解决。

        3. 董事会通过决议的做法符合《ICANN 章程》。

          请求人声称,由于“2019 年 5 月 15 日 ICANN 董事会会议的议程直到会议实际召开前一 (1) 天才发布”,故董事会通过决议的做法违反了《ICANN 章程》。28 在请求人看来,这违反了《ICANN 章程》第 3.4 条,其中规定“对于每次的董事会会议,应至少提前七天发布会议通知和已知的会议议程(若这种做法不切实际,则需尽量提前通知)。”29 正如请求人所说,章程中包含了类似“尽量”这样的限定词,这为这条规定“提供了一些灵活性”。30 在本案例中,2019 年 5 月 15 日会议是为了处理关于 gTLD 注册数据临时规范的 GNSO EPDP 建议的紧急事项,因为临时规范即将到期。31 考虑到这种情况,会议议程直到 2019 年 5 月 14 日才最终确定,并在确定后尽快发布了出来。因此,发布议程的时间符合章程的规定。

        4. 并未安排与 RySG 召开会议讨论修改 PIC 的潜在流程。

          BAMC 认为,由于 ICANN 组织与 RySG 在 ICANN65 期间并未私下安排会议讨论修改之前已达成一致意见的 PIC 的流程,故请求 19-1 称 ICANN 组织违反《ICANN 章程》、政策或程序的说法不成立,对此董事会表示赞同。相反,请求人引用的会议涉及的是强制执行 PIC 的流程(即公共利益承诺争议解决流程,简称 PICDRP)。

          基于上述原因,董事会最终认定没有必要启动重审。

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

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

    3. GAC 建议:马拉喀什公报(2019 年 6 月)

      鉴于政府咨询委员会 (GAC) 在摩洛哥马拉喀什举行的 ICANN65 会议期间召开了会议,并于 2019 年 6 月 27 日发布了公报(简称“马拉喀什公报”),其中包含对之前建议的跟进,但未提出新的共识性建议。对之前建议的跟进涉及到 .AMAZON 申请、作为二级域名的双字符国家代码以及 WHOIS 和数据保护。

      鉴于在 2019 年 7 月 19 日信函中,GNSO 理事会就马拉喀什公报中包含的对之前建议的跟进向董事会提供了反馈。

      鉴于董事会在考虑了其与 GAC 之间过去围绕此等主题的对话以及 GNSO 理事会提供的信息之后,制定了一张计分卡,用于回应 GAC 在马拉喀什公报中对之前建议的跟进。

      兹此发布第 2019.09.08.09 号决议:董事会采纳名为“GAC 建议 — 马拉喀什公报:行动和更新(2019 年 9 月 8 日)”的计分卡,以回应 GAC 在马拉喀什公报中对之前建议的跟进。

      第 2019.09.08.09 号决议的理由

      根据《ICANN 章程》第 12 条第 12.2(a)(ix) 款,GAC 可以“直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议”。在马拉喀什公报(2019 年 6 月 27 日)中,GAC 就之前关于 .AMAZON 申请、作为二级域名的双字符国家代码以及 WHOIS 和数据保护的建议发布了跟进。GAC 并未提供任何新的共识性建议《ICANN 章程》要求董事会在制定和采纳政策时考虑 GAC 对公共政策问题的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。对于 GAC 完全达成共识(按照章程规定)的任何 GAC 建议,只有不少于 60% 的董事会成员投反对票后才可予以否决。然后,GAC 和董事会必须尝试真诚、及时、高效地寻找双方都可以接受的解决方案。

      董事会今天是针对马拉喀什公报中的所有跟进事项采取行动。

      2019 年 9 月 8 日通过的计分卡中介绍了董事会的行动。

      在采纳对马拉喀什公报中 GAC 对之前建议的跟进的回应时,董事会审核了诸多材料,包括但不限于以下材料和文件:

      采纳计分卡中 GAC 对之前建议的跟进有助于解决 GAC 关于 gTLD 和其他事项的建议,将对社群产生积极影响。通过此项决议不会产生任何可预见的财务影响。批准此项决议不会产生任何与 DNS 相关的安全、稳定或弹性问题。这属于组织管理职能,无需征询公众意见。

1 《ICANN 章程》,2018 年 6 月 18 日,第 3 条第 3.4 款。

2 同上,第 3.1 款。

3 请求 19-1,第 8 节,第 5 页。

4同上,第 7 页。

5 关于共同治理模型,请求还要求“ICANN 组织指示 SSAC 编制一份报告,供 ICANN 董事会用于解决亚马逊公司就哥伦比亚政府提议的并行使用方案提出的安全和稳定问题。”请求 19-1,第 9 节,第 11 页。然而,此信息与当前处理的问题并无关系。此外,重审请求也不是用于请求这类救济的适当渠道。参见《章程》第 4 条第 4.2 款。同样,重审请求也不适合用于请求人请求 ICANN 董事会“收到关于‘未获批准或已撤回’的约 37 项规范 13 申请的机密简报文件。”请求 19-1,第 9 节,第 11 页。

6 同上,第 5 页。

7 同上,附件第 17 页。

8 同上

9请求人的 2019 年 4 月 7 日信函引用了多种联合治理模型,包括 .SAS TLD 治理模型。

14 参见 https://www.icann.org/en/system/files/correspondence/zaluar-to-chalaby-23apr19-en.pdfhttps://www.icann.org/en/system/files/correspondence/glaser-to-chalaby-29apr19-en.pdf 等。另请参见第 2019-05-15-1c 号文件附件 B 的 ICANN 参考材料 (https://www.icann.org/en/system/files/bm/briefing-materials-2-redacted-15may19-en.pdf)(说明了 2019 年 4 月 23 日巴西政府致 ICANN 的信函);2019 年 4 月 23 日巴西政府致 ICANN 的信函 (https://www.icann.org/en/system/files/correspondence/zaluar-to-chalaby-23apr19-en.pdf)(声称“所申请的字符串将作为封闭式品牌 gTLD 运营,这将阻止在 .AMAZON TLD 下出于保护和推广品牌以外的目的共享域名”)。

15 参见请求 19-1,第 8 节,第 7 页。

16 请求 19-1,第 8 节,第 6 页。

17 同上,第 8 节,第 6 页。

19 2019 年 4 月 17 日亚马逊致 ICANN 董事会的信函,第 3 页 (https://www.icann.org/en/system/files/correspondence/huseman-to-chalaby-17apr19-en.pdf)。

22 上。

23 请求 19-1,附件,第 2 页。

24 请求人要求董事会确认亚马逊公司提出的方案是否符合 ICANN 的政策和实践,如果该方案不符合 ICANN 的政策和实践,则重审决议。请求 19-1,第 8-9 节,第 7、11 页。这里存在一个基本问题,即,重审请求并非要求董事会“确认”董事会决定的适当渠道;在评估重审请求时,BAMC 和董事会会考虑董事会的行动(这里指的是决议)是否违反了 ICANN 的政策和程序。参见《章程》第 4 条第 4.2 款。BAMC 的结论是,这些决议符合 ICANN 的既定政策和程序,也符合《ICANN 章程》。因此,没有必要启动重审。

25 参见请求 19-1,第 8 节,第 6 页(“我们看不出亚马逊公司提出的允许 ACTO 成员国成为域名受益注册人的方案符合 ... 事实仍然是,ACTO 成员国将成为受益注册人,因此将违反规范 13 的条款。”)。

28 请求 19-1,第 8 节,第 9 页。

29 同上。

30 同上。

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