Skip to main content
Resources

会议记录 | ICANN 董事会例行会议

本页面还提供其他语种:

当地时间 2019 年 1 月 27 日 10: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 Alverstrand,IETF 联络人)、玛娜尔·伊斯梅尔(Manal Ismail,GAC 联络人)、梅里克·科欧(Merike Kaeo,SSAC 联络人)以及凯夫·兰吉巴(Kaveh Ranjbar,RSSAC 联络人)。

秘书长:约翰·杰弗里(John Jeffrey,总法律顾问兼秘书长)。

以下 ICANN 高级管理人员和工作人员参加了全部或部分会议:苏珊娜·宾内特(Susanna Bennett,首席运营官)、米歇尔·布莱特(Michelle Bright,董事会内容协调主管)、弗兰科·卡拉斯科(Franco Carrasco,董事会运营专家)、哈维尔·卡尔维兹(Xavier Calvez,高级副总裁兼首席财务官)、曼迪·卡维尔(Mandy Carver,政府合作全球协调副总裁)、莎莉·科亨(Sally Cohen,全球传播高级副总裁)、金·戴维斯(Kim Davies,IANA 服务副总裁兼 PTI 总裁)、莎曼珊·艾斯内(Samantha Eisner,副总法律顾问)、拉里萨·格尼克(Larisa Gurnick,多利益相关方战略和战略计划副总裁)、杰米·赫德伦(Jamie Hedlund,合同合规和消费者保护高级副总裁兼华盛顿哥伦比亚特区办公室总经理)、约翰·杰弗里(总法律顾问兼秘书长)、亚伦·吉美内兹(Aaron Jimenez,董事会运营高级协调人)、塔瑞克·卡梅尔(Tarek Kamel,总裁高级顾问兼政府和 IGO 合作部高级副总裁)、温西安·科尼格斯菲尔德(Vinciane Koenigsfeld,董事会运营主管)、伊丽莎白·李(Elizabeth Le,助理总法律顾问)、赛勒斯·那马兹(Cyrus Namazi,全球域名分部域名服务及行业合作副主席)、戴维·奥利佛(David Olive,政策制定支持部高级副总裁)、加西亚·奥利维拉(Cassia Oliveira,首席执行官办公室高级经理)、艾米莉·匹门特尔(Emily Pimentel,高级传播主管)、温迪·普若菲特(Wendy Profit,董事会运营高级经理)、埃里卡·兰德尔(Erika Randall,助理总法律顾问)、阿什文·兰根(Ashwin Rangan,工程部高级副总裁兼首席信息官)、丽莎·莎莉诺(Lisa Saulino,董事会运营高级协调人)、艾米·斯塔索斯(Amy Stathos,副总法律顾问)、特里莎·斯旺哈特(Theresa Swinehart,多利益相关方战略和战略计划高级副总裁)、尼克·托玛索(Nicholas Tomasso,全球会议运营副总裁兼中东和非洲地区总经理)、吉娜·比亚维森西奥(Gina Villavicencio,全球人力资源部高级副总裁)、克里斯汀·维雷特(Christine Willett,gTLD 运营副总裁)以及玛丽·王(Mary Wong,社群战略运营、规划与合作副总裁)。

  1. 认可议程:
    1. 批准会议记录
    2. 接受 GNSO2 审核工作组的最终实施报告
    3. 考量一般会员咨询委员会详细实施规划
    4. 2020 财年 IANA 运营规划和预算
    5. 2021 年 10 月 ICANN 会议会场签约
    6. ERP 方案 (Oracle Cloud) 合同续约与费用支付
    7. 重申《gTLD 注册数据临时规范》
  2. 主要议程:
    1. 将代表毛里塔尼亚的阿拉伯文国家和地区顶级域 موريتانيا. 授权给 Université de Nouakchott Al Aasriya
    2. 将国家和地区顶级域 .SS(南苏丹)授权给国家通信局 (NCA)
    3. GAC 建议:巴塞罗那公报(2018 年 10 月)
    4. 通过与域名系统二级域中的某些红十字会与红新月会名称有关的 GNSO 共识性政策
    5. 董事会委员会成员和领导层变动
    6. 对重审请求 16-11 的考量:Travel Reservations SRL、Famous Four Media Limited(及其子公司申请人 dot Hotel Limited)、Fegistry LLC、Minds + Machines Group Limited、Spring McCook, LLC 和 Radix FZC(及其子公司申请人 dot Hotel Inc.)(.HOTEL)
    7. 对重审请求 18-9 的考量:DotKids Foundation (.KIDS)
    8. 对重审请求 16-12 的考量:Merck KGaA (.MERCK)
    9. 其他事务
  1. 认可议程:

    主席介绍了认可议程中的事项。艾芙丽·多利亚提出动议,里昂·桑切斯表示支持。随后,主席发起投票,董事会采取了以下行动:

    1. 批准会议记录

      第 2019.01.27.01 号决议:董事会批准 ICANN 董事会 10 月 25 日例行会议和组织会议以及 ICANN 董事会 11 月 6 日特殊会议的会议记录。

    2. 接受 GNSO2 审核工作组的最终实施报告

      鉴于作为通用名称支持组织 (GNSO) 第二轮审核的一部分,董事会于 2017 年 2 月 3 日接受了 GNSO 审核实施规划并指示 GNSO 理事会向董事会提供有关实施工作的定期报告。

      鉴于 GNSO 审核工作组在 GNSO 理事会的批准和监督下,通过董事会组织效率委员会 (OEC) 向董事会提供了有关实施工作进度的半年更新报告,一直到实施工作结束时。

      鉴于 OEC 通过半年实施报告监督了实施工作的进度,并建议董事会接受 GNSO 审核工作组发布并由 GNSO 理事会于 2018 年 8 月 16 日批准的第二轮 GNSO 审核最终实施报告。

      兹此发布第 2019.01.27.02 号决议:董事会认可 GNSO 审核工作组所做的辛勤工作,并感谢他们根据采纳的 GNSO 审核实施规划中拟定的时间表编制建议实施报告来提高 GNSO 的效率、透明度和问责制。

      第 2019.01.27.03 号决议:董事会接受 GNSO 审核工作组发布的第二轮 GNSO 审核 (GNSO2) 最终实施报告。此举也标志着这一重要审核工作现已结束。董事会鼓励 GNSO 继续监督实施第二轮 GNSO 审核建议的影响,以此作为其持续改进流程的一部分。

      第 2019.01.27.02 – 2019.01.27.03 号决议的理由

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

      为确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其绩效,ICANN 依照《ICANN 章程》第 4 条第 4.4 款所述,对其支持组织和咨询委员会进行独立审核。

      这项行动结束了第二轮 GNSO 审查,并以 GNSO 理事会采纳的最终实施报告、独立审核人 Westlake Governance 的最终报告以及 GNSO 审核工作组 (WG) 对 GNSO 理事会采纳的建议进行的评估为依据。在 OEC 评估所有相关文件和社群反馈后,董事会当前正考虑并计划接受最终实施报告。

      根据董事会组织效率委员会 (OEC) 的建议,董事会考虑了所有相关文件,包括最终报告、GNSO 审核工作组可行性评估和独立审核人建议的优先级(下称“可行性评估”),并接受了独立审核人于 2016 年 6 月 25 日发布的最终报告。除建议 23 和 32 以外,董事会采纳了该可行性评估。此外,董事会指示 GNSO 理事会:考虑到社群工作任务始终繁重和 WG 提议的优先级,起草一个实施规划来落实采纳的建议,其中包含实际可行的时间表;在董事会采纳可行性评估后六 (6) 个月内公布该规划;确保实施规划包括预期成果的定义、当前状态的衡量方式和实现预期成果的实施进度;以及定期向董事会汇报其实施进度。

      2017 年 2 月 3 日,董事会接受了 WG 提交并由 GNSO 理事会于 2016 年 12 月 15 日批准的实施规划,同时指示 WG 向 OEC 提供半年更新报告,一直到实施工作结束时。

      正在考虑的提案是什么?

      正在考虑的提案是由董事会接受 GNSO 理事会采纳并经过 OEC 考量的 WG 最终实施报告。

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

      董事会通过 OEC 咨询了负责实施工作的 GNSO 审核工作组,建议了及时进行有效审核的良好实践,并监督了审核的进度以及实施审核建议的进度。

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

      GNSO 在执行实施工作时遵循了其标准惯例以改善透明度和问责制。社群未提供任何疑虑。

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

      董事会审核了相关《章程》条款组织审核流程文件GNSO 审核建议实施规划和 GNSO 审核工作组的最终实施报告

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

      董事会认为有一些因素对于高效完成实施工作至关重要:

      • 成立专门小组来监督董事会接受的建议的实施情况
      • 制定实施规划,其中包含实际可行的实施时间表、预期成果的定义、当前状态的衡量方式和实现预期成果的实施进度
      • 及时、详细地报告实施进度

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

      通过确认并强调以高效的方式完成 GNSO 审核建议实施工作,此项董事会行动预计会对社群产生积极影响。

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

      由于实施工作已成功完成,此项董事会行动预计不会产生财务影响。预计会对 ICANN 组织、社群和公众产生积极影响,因为此项董事会行动为 ICANN 的组织审核和自我治理树立了重要里程碑。

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

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

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

      董事会的行动符合 ICANN 根据《章程》第 4.1 条做出的承诺,即持续审核 ICANN 内部各实体的现有职能并提高其支持组织和咨询委员会的绩效。通过履行 ICANN 的承诺,即持续对其内部各实体进行审核,以确认这些实体中的人员与 ICANN 社群合作来支持达到合作的目的和期望,该行动将服务于公共利益。

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

      无需征询公众意见。

    3. 考量一般会员咨询委员会详细实施规划

      鉴于《ICANN 章程》第 4 条第 4.4 款要求 ICANN 董事会“由独立于被审核组织的实体定期审核各个支持组织、各个支持组织理事会、各个咨询委员会(政府咨询委员会除外)以及提名委员会的绩效和运营情况。根据董事会规定的标准所进行的审核的目标应该是确定 (i) 作为 ICANN 组织结构的一部分,该组织是否具有长期的目标,(ii) 如果有的话,那么对其结构或运作方式的任何更改是否有助于提高其效力。”

      鉴于一般会员审核的独立审核人于 2017 年 2 月编制了一份最终报告。董事会于 2018 年 6 月收到该报告,同时,董事会接受了 ALAC 批准的一般会员审核建议可行性评估和实施规划以及一般会员审核实施概述提案。

      鉴于为了响应 2018 年 6 月的决议,组建了一般会员审核实施工作组。该工作组于 2018 年 11 月 19 日制定并批准了一般会员审核实施规划(下称“实施规划”),ALAC 于 2018 年 11 月 27 日发布支持声明表示支持该规划。

      兹此发布第 2019.01.27.04 号决议:董事会认可一般会员审核实施工作组的工作并对工作组成员付出的努力表示感谢。

      第 2019.01.27.05 号决议:董事会接受一般会员审核实施规划,包括本规划中确定的分期方案。董事会确认,实施第 2 和第 3 优先级活动时,可能需要更多与实施有关的细节。

      第 2019.01.27.06 号决议:董事会指示一般会员审核实施工作组每六个月向 OEC 汇报一次最新情况。这些一年两次的汇报将确定根据现有实施规划衡量的成就,以及有关未来实施规划的细节。汇报期间,一般会员审核实施工作组应提供实施进度和可衡量性方面的更多细节。如有必要,OEC 可要求进行临时简报。

      第 2019.01.27.07 号决议:在适用的年度预算制定流程中,应考虑实施一般会员审核的任何预算影响。

      第 2019.01.27.04 – 2019.01.27.07 号决议的理由

      为确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其绩效,ICANN 依照《ICANN 章程》第 4 条第 4.4 款所述,对其支持组织和咨询委员会组织开展独立审核。第二次一般会员审核于 2016 年启动,独立审核人于 2017 年 5 月呈交其最终报告。

      一般会员审核实施概述提案中提出的一般会员审核实施建议能够改进 ICANN 的透明度和问责制目标,目前已经过董事会组织效率委员会以及整个董事会的审慎考虑。

      该董事会决议将对 ICANN,尤其是 ALAC 和一般会员社群产生积极影响,因为它将进一步加强 ICANN 以及 ALAC 和一般会员社群对在整个实施流程中维持和改进其问责制、透明度和组织效率的承诺。

      由于有大量的建议需要实施,董事会支持采取实施规划中所述的优先级方法(附录 A)。此举可在不中断实施流程的情况下,使社群有时间完善细节内容 – 尤其是在实施规划规定的第 2 和第 3 优先级活动期间。

      提供额外的实施细节可能有助于实施部分建议,特别是预计在第 2 和第 3 优先级活动下实施的建议。由于难以提前数月预测这些问题,董事会支持一般会员审核实施工作组每半年向 OEC 汇报一次最新情况的观点。每次汇报时,ALAC 可针对计划在汇报后六个月内实施的建议向 OEC 提供更多实施细节。那时,ALAC 将能更好地指明与初始实施规划和时间安排存在的任何重大差异。一般会员审核实施规划说明了建议的优先级;员工时间、网络和维客资源方面的预计资源分配;预期的预算影响(如其他员工资源)以及实施步骤。虽然大多数实施活动将使用现有的一般会员资源,但下文提到了任何其他财务影响。ALAC 将利用正常的年度预算公众意见征询流程来申请所需资源。如果未提供此类资源,审核实施的速度可能会大大降低。

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

      本决议旨在推动第二轮一般会员社群审核进入实施阶段。继评估实施规划和董事会组织效率委员提供的反馈之后,当前,董事会正在考虑该规划并指示 ALAC 继续完成规划中指定的实施流程。此步骤是组织审核流程制衡措施的重要部分,可在考虑到预算和时间安排限制的情况下,确保通过实施规划贯彻董事会批准的建议的精神。

      正在考虑的提案是什么?

      董事会正在考虑的提案是组织效率委员会的建议,即通过由一般会员审核实施工作组起草并采纳、并获得 ALAC 支持的一般会员审核实施规划。

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

      在董事会通过有关一般会员审核的决议后,一般会员审核工作组的领导层在五次 RALO 月度电话会议中汇报了审核的最新动态以及后续步骤。成立一般会员审核实施工作组需要成员进行仔细考量,以确保每个 RALO(包括 232 个一般会员组织和 100 多位个人会员)内部的地理平衡和多样性。在制定一般会员审核实施规划期间,一般会员审核工作组成员定期向 ALAC 和每个 RALO 汇报了最新进展。在第 63 届 ICANN 面对面会议期间,还就一般会员审核实施展开了一些讨论。在每个步骤中,一般会员审核实施工作组都讨论了收到的反馈并将其纳入最终计划中。

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

      在制定一般会员审核实施规划期间,一般会员社群就是否举办暂定于 2019 年 10 月在第 66 届 ICANN 蒙特利尔会议期间召开的第三届一般会员峰会 (ATLAS III) 提出顾虑,并将其确定为需要在更广泛的组织预算周期之前做出预算考量的第 1 优先级活动。2018 年 9 月,董事会确认 ICANN 组织仍有权继续进行规划和签约。

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

      董事会审核了一般会员审核实施工作组采纳并获得 ALAC 支持的一般会员审核实施规划。

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

      要通过落实审核中发现的问题和实施一般会员审核概述提案来提高一般会员组织的效率,可能需要通过 ICANN 的常规预算流程申请其他财务资源。此决议并未针对那些实施工作授权任何专项资金。董事会理解,一些第 1 优先级工作(如技能培养和宣传工作)将需要通过 2020 财年额外预算请求来申请资金。此外,董事会也理解,正在进行的活动以及第 2 优先级活动估计需要增加一个全职人力工时,并且宣传和数据收集等事项预计也会产生其他资源需求。

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

      该行动预计不会对 DNS 的安全、稳定或弹性造成直接影响。但是,在实施改进措施后,ALAC 和一般会员社群未来的活动(包括为政策制定流程提供建议或意见)将会变得更透明和负责,这反过来可能会间接促进 DNS 的安全性、稳定性或弹性。

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

      已发布独立审核人的报告草案以征询公众意见。在董事会采取行动前,无需征询公众意见。通过制定 ALAC 实施概述提案的一般会员审核工作组、编制实施规划的一般会员审核实施工作组和采纳实施规划的 ALAC,ALAC 的意见在整个审核流程中得到充分体现。

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

      由于在 ICANN 多利益相关方治理方法中,一般会员代表着个人互联网最终用户的最佳利益,因此,批准一般会员审核实施规划将巩固一般会员社群,并会在其自下而上的政策制定流程中对 ICANN 的使命产生直接的积极影响。此行动将推动多样化、博识的多利益相关方社群的持续发展并为其提供进一步支持,因此也服务于公共利益。

    4. 2020 财年 IANA 运营规划和预算

      鉴于已依照《ICANN 章程》于 2018 年 9 月 28 日发布 2020 财年 IANA 运营规划和预算 (OP&B) 草案以征询公众意见。

      鉴于已审核并回复通过公众意见征询流程收到的意见,并将其提供给 BFC 成员进行审核与评议。

      鉴于已考虑所有公众意见,并将适当、可行的意见纳入 2020 财年最终 IANA OP&B。

      鉴于公共技术标识符董事会于 2018 年 12 月 20 日采纳了 2020 财年最终 PTI OP&B,它是 ICANN 董事会考量更广泛的 IANA OP&B 时需要考虑的意见。依照《ICANN 章程》,一旦 ICANN 董事会采纳 IANA OP&B,将在 ICANN 网站上发布该 OP&B,以便赋权社群有机会考虑 IANA OP&B 以给出拒绝意见。

      鉴于收到的公众意见以及寻求的其他社群反馈均已被纳入考虑范围,以确定 2020 财年 IANA 运营计划和预算草案需要进行哪些修订。

      兹此发布第 2019.01.27.08 号决议:董事会采纳 2020 财年 IANA 运营规划和预算,包括 2020 财年 IANA 看守预算。

      第 2019.01.27.08 号决议的理由

      根据《ICANN 章程》第 22.4 款,董事会负责通过 IANA 职能运营的年度预算并将该预算发布到 ICANN 网站上。2020 财年 PTI O&B 草案和 2020 财年 IANA OP&B 草案已于 2018 年 9 月 28 日发布以征询公众意见。PTI 董事会于 2018 年 12 月 20 日批准了 PTI 预算,PTI 预算为 2020 财年 IANA 预算提供了参考信息。

      发布的 2020 财年 PTI OP&B 草案以及 2020 财年 IANA OP&B 草案是在与 ICANN 组织成员和 ICANN 社群进行多次讨论的基础上制定的,包括在发布之前的几个月与 ICANN 支持组织、咨询委员会和其他利益相关方团体进行广泛协商。

      在编制 2020 财年 IANA OP&B 期间考虑了以各种方式收到的所有意见。在可行和适当的情况下,这些意见被纳入提请批准的 2020 财年最终 IANA OP&B。

      2020 财年 IANA OP&B 将对 ICANN 产生积极影响,因为它提供了一个执行 IANA 服务的适当框架,也为组织奠定了以透明方式负责的基础。

      此项决定符合公共利益并与 ICANN 的使命相一致,因为它完全符合 ICANN 的战略和运营计划,其结果实际上也有利于 ICANN 履行其使命。

      此决定将对 ICANN 和所针对的社群产生财务影响。就针对域名系统 (DNS) 的安全、稳定与弹性方面的资金而言,该决定应该会对 DNS 的这些方面产生积极影响。

      这属于组织管理职能,已征询公众意见(如上所述)。ICANN 的赋权社群现在有机会考虑是否对此 OB&P 行使拒绝权力。

    5. 2021 年 10 月 ICANN 会议会场签约

      鉴于 ICANN 拟将 2021 年最后一场公共会议的地点选在北美地区。

      鉴于 ICANN 组织已完成了对北美地区可用会场的全面审核,认为位于华盛顿州西雅图市的一个会场最为合适。

      兹此发布第 2019.01.27.09 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进与 2021 年 10 月在华盛顿州西雅图市举办的 ICANN 公共会议会场相关的所有必要的合同签订和费用支付工作,总金额不超过[协商一致后确定的金额]。

      第 2019.01.27.10 号决议:出于谈判目的,该决议中的具体条款应按照《ICANN 章程》第 III 条第 5.2 款的规定进行保密,保密期截至总裁兼首席执行官认为可以发布保密信息为止。

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

      第 2019.01.27.09 – 2019.01.27.11 号决议的理由

      作为 ICANN 公共会议策略的一部分,ICANN 争取每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。第 72 届 ICANN 会议预计将在 2021 年 10 月 23 日至 28 日召开。研究并评估可用会场后,组织确定华盛顿州西雅图市为举办 ICANN 公共会议的合适场地。

      组织对所有可用会场进行了全面分析并编制了一份报告,以确定那些符合“会议选址标准”(参见 http://meetings.icann.org/location-selection-criteria)的会场。依据提案和分析,ICANN 确认将华盛顿州西雅图市作为第 72 届 ICANN 会议的举办地。选择此北美地区会场时遵循了会议策略工作组制定的地理区域轮换指南。

      董事会审核了组织关于在华盛顿州西雅图市举行会议的简报以及与 2021 年 10 月 ICANN 公共会议所选设施相关的成本,认为提案符合“会议选址标准”中的重要因素。ICANN 通过召开公共会议来支持其确保互联网唯一标识符系统的稳定和安全运营的使命,并通过为希望参与(无论是亲自参与,还是远程参与)开放、透明和自下而上的多利益相关方政策制定流程的任何人提供免费和开放的机会,以符合公共利益的方式行事。

      主办会议并提供必要的差旅补助会对 ICANN 产生财务影响,承担会议差旅成本也会给社群带来财务影响。但是,无论会议的举办地点和会场在何处,都必须面临这些影响。此项行动不会对 DNS 的安全性或稳定性造成任何影响。

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

    6. ERP 方案 (Oracle Cloud) 合同续约与费用支付

      鉴于 ICANN 已确定需要续签 ERP 解决方案 Oracle Cloud 的合同。

      鉴于董事会财务委员会已审核续签与 ICANN 的 ERP 解决方案 Oracle Cloud 有关的合同的财务影响并考虑了备选方案。

      鉴于组织和董事会财务委员会都建议董事会授权主席兼首席执行官或其指定人员采取所有必要行动签署与 ICANN 的 ERP 解决方案 Oracle Cloud 有关的合同并根据这些合同支付所需款项。

      兹此发布第 2019.01.27.12 号决议:董事会授权主席兼首席执行官或其指定人采取所有必要行动续签与 ICANN 的 ERP 解决方案 Oracle Cloud 有关的合同并根据这些合同支付所需款项。

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

      第 2019.01.27.12 – 2019.01.27.13 号决议的理由

      自 2016 年 12 月开始实施以来,ICANN 已成功利用了 Oracle Cloud ERP。过去几年来,ICANN 组织已逐渐掌握了 ERP 系统和事务处理知识,并能够不断提高效率以实现原始投资最大化。Oracle Cloud ERP 取代了当时遗留的陈旧财务、人力资源和采购系统。此解决方案通过单一记录系统为 ICANN 组织提供了集成式 ERP 解决方案,提高了系统容量、全球报告和分析能力,改进了生产率和跨职能效率,并加强了内部控制。

      当前合同

      ICANN 当前的 Oracle Cloud ERP 合同期限为三年。此合同已于 2018 年 12 月到期。Oracle Cloud 为 ICANN 提供了一个月的合同延期。年度成本为[协商一致后确定的金额]

      新合同

      与供应商一起进行全面分析、谈判并调整许可证数量后,组织有两个可选方案:(i) 以每年[协商一致后确定的金额]的费用签订三年合同,三年的总费用为[协商一致后确定的金额],(ii) 以每年[协商一致后确定的金额]的费用签订五年合同,五年的总费用为[协商一致后确定的金额]

      仔细分析组织提交的方案后,认为五年合同方案是可行、具有成本效益的解决方案。此解决方案的总费用更低,通过锁定定价来防止在今后五年内提价,并具有灵活性,便于组织在三年内(2021-2022 年)执行另一次整体 ERP 系统分析以确定此解决方案是否是 ICANN 的最佳选择。

      董事会审核了组织和董事会财务委员会就续签 Oracle Cloud ERP 合同的签约和支付权限而提出的建议。

      采取这项董事会行动正好符合 ICANN 的使命和公共利益,因为它可以确保在支付给某个实体的大额发票超过 ICANN 的签约和支出政策授权的特定金额时,由董事会进行审核和评估。这可以确保董事会对大额支出进行监督,并适当管理 ICANN 接受的来自公众的资助。

      续签 Oracle Cloud ERP 合同会对 ICANN 产生财务影响。此影响当前已纳入正等待董事会审批的 2020 财年运营规划和预算中。该行动不会对域名系统的安全、稳定与弹性产生直接影响。

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

    7. 重申《gTLD 注册数据临时规范》

      鉴于 2018 年 5 月 17 日,董事会采纳了《gTLD 注册数据临时规范》(下称“《临时规范》”),于 2018 年 5 月 25 日生效,有效期为 90 天。考虑到欧盟的《通用数据保护条例》(GDPR),该《临时规范》确定了相关的临时要求,允许 ICANN 以及 gTLD 注册管理运行机构和注册服务机构继续遵守与 gTLD 注册数据(包括 WHOIS)有关的现有 ICANN 合规要求和社群制定的政策。

      鉴于 2018 年 8 月 21 日,董事会重申采纳《临时规范》,从 2018 年 8 月 23 日开始,有效期延长 90 天。

      鉴于 2018 年 11 月 6 日,董事会重申采纳《临时规范》,从 2018 年 11 月 21 日开始,有效期延长 90 天。

      鉴于董事会根据《注册管理机构协议》和《注册服务机构认证协议》中有关采纳临时政策的程序采纳了《临时规范》。该程序要求,“如果采纳临时政策的时间段超过九十 (90) 日,董事会应每九十 (90) 日(总计不超过一 [1] 年)重申其临时采纳以保持此类临时政策有效,直至其成为共识性政策。”

      兹此发布第 2019.01.27.14 号决议:董事会根据《注册管理机构协议》和《注册服务机构认证协议》中有关制定临时政策的程序重申了《gTLD 注册数据临时规范》。在重申该《临时规范》时,董事会确定:

      1. 《临时规范》对注册数据中个人资料的现有处理要求的修改仍是合理的,并且仍然有必要立即临时制定临时规范,以维护注册服务机构服务、注册管理机构服务、DNS 或互联网的稳定性或安全性。
      2. 《临时规范》应尽可能严密设计以达成维护注册服务机构服务、注册管理机构服务、DNS 或互联网的稳定性或安全性的目标。
      3. 从 2019 年 2 月 19 日开始,《临时规范》的有效期将延长 90 天。

      第 2019.01.27.14 号决议:董事会重申有关采纳 gTLD 注册数据临时规范的咨询声明,其中详细解释了采纳临时规范的原因以及董事会为何认为该临时规范应得到互联网利益相关方的一致支持。

      第 2019.01.27.14 – 2019.01.27.15 号决议的理由

      欧盟《通用数据保护条例》(GDPR) 于 2018 年 5 月 25 日生效。GDPR 是欧洲议会、欧洲理事会和欧洲委员会通过的一套条例,该条例对收集和维护欧盟居民(定义见欧盟数据保护法)的任何“个人资料”的所有公司和组织强加了新的义务。GDPR 影响 gTLD 域名生态系统参与者(包括注册管理机构和注册服务机构)根据 ICANN 合同和政策收集、显示和处理个人资料的方式。

      2018 年 5 月 17 日,董事会采纳了《gTLD 注册数据临时规范》(下称“《临时规范》”),确立了与 GDPR 有关的临时要求,允许 ICANN 以及 gTLD 注册管理运行机构和注册服务机构继续遵守与 gTLD 注册数据(包括 WHOIS)有关的现有 ICANN 合规要求和社群制定的政策。该《临时规范》(于 2018 年 5 月 25 日生效)是根据《注册管理机构协议》和《注册服务机构认证协议》中确定的临时政策程序采纳的。

      2018 年 8 月 21 日,董事会重申《临时规范》,从 2018 年 8 月 23 日开始,有效期延长 90 天。2018 年 11 月 6 日,董事会再次重申采纳《临时规范》,从 2018 年 11 月 21 日开始,有效期延长 90 天。

      按照《注册服务机构认证协议》和《注册管理机构协议》中有关采纳临时政策或规范的程序,“如果采纳临时政策的时间段超过九十 (90) 日,董事会应每九十 (90) 日(总计不超过一 [1] 年)重申其临时采纳以保持此类临时政策有效,直至其成为共识性政策。”

      由于临时要求仍然是合理的,为了维护注册服务机构服务、注册管理机构服务或 DNS 的稳定性或安全性,目前董事会正在采取行动重申《临时规范》,重申时长达 90 天。在采纳《临时规范》时,董事会提供了咨询声明,详细说明了采纳《临时规范》的原因以及董事会认为该《临时规范》应获得互联网利益相关方一致支持的原因。董事会重申了该咨询声明,该咨询声明通过引用纳入董事会决议的理由中。

      在采纳临时政策或规范时,董事会根据需要采取措施实施了共识性政策的政策制定流程,并就下一步考虑针对《临时规范》中的问题制定共识性政策的潜在路径咨询了 GNSO 理事会。共识性政策的政策制定流程必须在一年内结束。董事会注意到,GNSO 理事会启动了一个有关《临时规范》的快速政策制定流程,工作组正在继续考虑提出拟定的政策建议。2018 年 11 月 21 日,工作组发布 gTLD 注册数据临时规范快速政策制定流程 (EPDP) 初步报告以征询公众意见。工作组于 2019 年 2 月制定了编制最终报告的时间表,以便在为《临时规范》提供的 1 年期限到期之前向董事会提交报告供其考量。董事会将继续与 GNSO 理事会就此事项展开合作,并重申了对按期完成快速政策制定流程工作提供必要支持的承诺(参见 2018 年 8 月 7 日谢林·查拉比 [Cherine Chalaby] 致 GNSO 理事会的信函:https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf)。

      董事会重申《临时规范》的行动符合 ICANN 的使命“[……]确保互联网的唯一标识符系统的稳定和安全运营[……]”。由于 ICANN 的其中一项主要职责是负责管理最高级的互联网标识符,促进识别这些标识符的持有者是 ICANN 的一项核心职能。董事会今天采取的行动将有助于为公共利益服务并促进满足《ICANN 章程》中规定的“评估当前 gTLD 注册管理机构目录服务的有效性,以及这项服务的推行是否能够满足执法工作的合理需求、促进消费者信任和保护注册人数据”的要求。[《章程》第4.6(e)(ii) 款]

      另外,这项行动预计会对 DNS 的持续安全、稳定或弹性产生直接影响,因为在社群努力制定共识性政策的同时,它将在可能的最大范围内协助继续维护 WHOIS。重申《临时规范》预计不会对 ICANN 组织产生超出先前在董事会第 2018.05.17.01 – 2018.05.17.09 号决议的理由中确定的财务影响。如果资源需求超过就 WHOIS 和 GDPR 相关问题开展工作的当前预算金额,总裁兼首席执行官将根据现有的资金申请惯例,向董事会财务委员会提出任何额外资源需求以供考虑。

      这属于董事会的组织管理职能,不需要征询公众意见,但 ICANN 解决遵守与 GDPR 有关的、涉及 gTLD 注册数据的 ICANN 政策和协议的方法已在去年接受了社群的评议 (https://www.icann.org/dataprotectionprivacy)。

    所有董事会成员以口头表决的方式批准第 2019.01.27.01、2019.01.27.02、2019.01.27.03、2019.01.27.04、2019.01.27.05、2019.01.27.06、2019.01.27.07、2019.01.27.08、2019.01.27.09、2019.01.27.10、2019.01.27.11、2019.01.27.12、2019.01.27.13、2019.01.27.14 和 2019.01.27.15 号决议。决议通过。

  2. 主要议程:

    1. 将代表毛里塔尼亚的阿拉伯文国家和地区顶级域 موريتانيا. 授权给 Université de Nouakchott Al Aasriya

      艾芙丽·多利亚介绍了此议程事项。尼戈尔·罗伯茨解释说,他请求将议程事项加入主要议程,是为了确保透明度,而不是因为相关授权存在争议。尼戈尔表示,他收到了一些具体反馈,指出国家和地区顶级域 (ccTLD) 社群的一些成员希望在将这些决议提交到董事会时提高透明度。尼戈尔进一步指出,在为 ASCII ccTLD 选择字符串上,IANA 和 PTI 没有选择;这是国际标准化组织负责的事务。ccTLD 的运营极其尊重辅助性原则,并且 ccTLD 经理人会考虑全球公共利益。

      尼戈尔提出动议并得到卡勒德·库巴的支持。随后,主席发起投票,董事会采取了以下行动:

      第 2019.01.27.16 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,PTI 审核并评估了将国家和地区顶级域 موريتانيا. 授权给 Université de Nouakchott Al Aasriya 的请求。相关文件证明,在评估该请求时遵循了适当的程序。

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

      第 2019.01.27.16 号决议的理由

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

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

      正在考虑的提案是什么?

      提案计划批准创建阿拉伯文国家和地区顶级域 موريتانيا. 并将管理机构的角色分配给 Université de Nouakchott Al Aasriya 的请求。

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

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

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

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

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

      董事会审核了以下评估:

      • 该域名具备授权资格,因为它是经 IDN ccTLD 快速通道流程批准的字符串,且代表 ISO 3166-1 标准中列出的国家或地区;
      • 已咨询过相关政府的意见,且政府并无异议;
      • 提议的管理机构及其联系人同意承担管理该域名的职责;
      • 提案体现了本地互联网社群的适当协商和支持;
      • 提案与任何已知法律或法规不抵触;
      • 提案确保了该域名在该国本地管理,并受当地法律约束;
      • 提议的管理机构已确认,他们将以公平、公正的方式管理该域名;
      • 提议的管理机构已证明拥有运营该域名所需的适当运营和技术能力、计划;
      • 提议的技术配置符合技术合规要求;
      • 未发现关于互联网稳定性的具体风险或顾虑;以及
      • 工作人员已建议根据考虑的各方面因素实施该请求。

      这些评估响应了适当的标准和政策框架,例如《域名系统结构和授权》(RFC 1591) 以及《国家和地区顶级域授权和管理的 GAC 原则与指导方针》。

      其他域名授权和转让报告请访问:http://www.iana.org/reports

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

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

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

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

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

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

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

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

    2. 将国家和地区顶级域 .SS(南苏丹)授权给国家通信局 (NCA)

      艾芙丽·多利亚介绍了此议程事项。尼戈尔·罗伯茨表示,他对议程项目 2.a. 提出的意见适用于此议程事项。

      卡勒德·库巴提出动议并得到尼戈尔的支持。随后,主席发起投票,董事会采取了以下行动:

      第 2019.01.27.17 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,PTI 审核并评估了将国家和地区顶级域 .SS(南苏丹)授权给国家通信局 (NCA) 的请求。相关文件证明,在评估该请求时遵循了适当的程序。

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

      第 2019.01.27.17 号决议的理由

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

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

      正在考虑的提案是什么?

      提案计划批准创建国家和地区顶级域 .SS 并将管理机构的角色分配给国家通信局 (NCA) 的请求。

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

      在评估授权申请的过程中,PTI 咨询了申请人和其他利益相关方。在申请过程中,申请人需要说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其对重要利益相关方的适用性。

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

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

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

      董事会审核了以下评估:

      • 该域名具备授权资格,因为南苏丹的该字符串当前已列入 ISO 3166-1 标准;
      • 已咨询过相关政府的意见,且政府并无异议;
      • 提议的管理机构及其联系人同意承担管理该域名的职责;
      • 提案体现了重要利益相关方的适当协商和支持;
      • 提案与任何已知法律或法规不抵触;
      • 提案确保了该域名在该国本地管理,并受当地法律约束;
      • 提议的管理机构已确认,他们将以公平、公正的方式管理该域名;
      • 提议的管理机构已证明拥有运营该域名所需的适当运营和技术能力、计划;
      • 提议的技术配置符合技术合规要求;
      • 未发现关于互联网稳定性的具体风险或顾虑;以及
      • 工作人员已建议根据考虑的各方面因素实施该请求。

      这些评估响应了适当的标准和政策框架,例如《域名系统结构和授权》(RFC 1591) 以及《国家和地区顶级域授权和管理的 GAC 原则与指导方针》。

      其他域名授权和转让报告请访问 http://www.iana.org/reports

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

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

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

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

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

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

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

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

    3. GAC 建议:巴塞罗那公报(2018 年 10 月)

      玛盾·波特曼介绍了此议程事项,该议程事项要求董事会批准题为“GAC 建议 — 巴塞罗那公报:行动与更新(2019 年 1 月 25 日)”的计分卡,该计分卡是为了回应 GAC 在巴塞罗那公报和巴拿马公报中所提出的建议内容而制定的。玛盾解释称,该计分卡考虑了董事会与 GAC 之间的对话、GAC 主席提交的澄清信函以及 GNSO 理事会提供的信息。此外,该计分卡还考虑了 ICANN 组织发布的备忘录和简报文件,该备忘录和简报文件说明了 ICANN 组织二级域双字符标签释放流程的发展和演化以及避免与相应的国家和地区代码混淆的标准措施框架。

      贝基·伯尔、主席和玛娜尔·伊斯梅尔感谢 ICANN 组织做出了大量与双字符问题有关的工作。

      玛盾提出动议并得到贝基的支持。随后,主席发起投票,董事会采取了以下行动:

      鉴于政府咨询委员会 (GAC) 在 ICANN 第 63 届西班牙巴塞罗那会议期间举行了会议,并在 2018 年 10 月 25 日的公报(下称“巴塞罗那公报”)中公布了向 ICANN 董事会提出的建议。

      鉴于巴塞罗那公报是董事会与 GAC 于 2018 年 11 月 28 日进行的沟通的主题。

      鉴于在 2018 年 12 月 20 日的信函中,GAC 对题为“针对 ALAC 和 GAC 原始联合声明(阿布扎比,2017 年 11 月 2 日)提出的跟进建议”的巴塞罗那公报附录中包含的陈述提供了额外说明。

      鉴于在 2018 年 12 月 21 日的信函中,GNSO 理事会就巴塞罗那公报中与通用顶级域相关的建议向董事会提供了反馈,便于董事会及社群了解可能与 GAC 建议相关的 gTLD 政策活动。

      鉴于 ICANN 组织公布了备忘录历史简报文件,说明了 ICANN 组织二级域双字符标签释放流程的发展和演化以及避免与相应的国家和地区代码混淆的标准措施框架。

      鉴于考虑到董事会与 GAC 之间的对话、GAC 主席提交的澄清信函、GNSO 理事会提供的信息以及 ICANN 组织发布的备忘录和简报文件,董事会制定了计分卡来响应 GAC 在巴塞罗那公报中提出的建议。

      鉴于董事会考虑了巴拿马公报中与二级域双字符国家和地区代码有关的先前推迟实施的 GAC 建议,并在当前计分卡“GAC 建议 – 巴塞罗那公报:行动与更新(2019 年 1 月 25 日)”中做出了回复。

      兹此发布第 2019.01.27.18 号决议:董事会采纳题为“GAC 建议 — 巴塞罗那公报:行动与更新(2019 年 1 月 25 日)”的计分卡,回应 GAC 在巴塞罗那公报和巴拿马公报中所提出的建议内容。

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

      第 2019.01.27.18 号决议的理由

      根据《ICANN 章程》第 12 条第 12.2(a)(ix) 款,GAC 可以“直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议”。在其巴塞罗那公报(2018 年 10 月 25 日)中,GAC 就以下事项向董事会提出了建议:二级域双字符国家和地区代码以及保护 gTLD 中国际政府间组织 (IGO) 的名称和缩写词。此外,GAC 还针对先前有关 GDPR 和 WHOIS 的建议、.Amazon 申请、保护红十字会和红新月会名称和标识符提供了跟进建议,并针对 ALAC 和 GAC 联合声明(阿布扎比,2017 年 11 月 2 日)提供了跟进建议。《ICANN 章程》要求董事会在制定和采纳政策时考虑 GAC 就公共政策问题提供的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。对于 GAC 完全达成共识(按照《章程》规定)的任何 GAC 建议,只有不少于 60% 的董事会成员投反对票后才可予以否决。然后,GAC 和董事会必须尝试真诚、及时、高效地寻找双方都可以接受的解决方案。

      董事会当前正对巴塞罗那公报中的所有建议内容(包括与二级域双字符国家和地区代码以及保护 IGO 有关的建议内容)采取行动。此外,董事会也正在对巴拿马公报中与二级域双字符国家和地区代码有关的建议内容采取行动,此前已推迟对该建议内容的考虑。

      董事会将继续推迟考虑圣胡安公报中的五项建议,包括四项与 GDPR 和 WHOIS 有关的建议和一项与 IGO 保留缩写词有关的建议,等待进一步与 GAC 展开讨论。董事会将在进行这些讨论之后,确定是否需要采取进一步行动。

      2019 年 1 月 25 日的计分卡中介绍了董事会的行动。

      在采纳对巴塞罗那公报中 GAC 建议的回应时,董事会审核了诸多材料,包括但不限于以下材料和文件:

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

    4. 通过与域名系统二级域中的某些红十字会与红新月会名称有关的 GNSO 共识性政策

      克里斯·狄思潘介绍了此议程事项。此决议遵循了通用名称支持组织 (GNSO) 提出的政策建议。克里斯指出,为了达成共识,GNSO 与政府咨询委员会进行了较高级别的讨论和合作。

      克里斯提出动议并得到马修·希尔斯的支持。随后,主席发起投票,董事会采取了以下行动:

      鉴于 2017 年 3 月,通用名称支持组织(下称“GNSO”)和政府咨询委员会(下称“GAC”)进行了促进性的友好对话,尝试解决 GNSO 的原始政策制定流程(下称“PDP”)共识性建议与 GAC 就某些红十字会和红新月会名称提出的建议之间存在的明显分歧。

      鉴于在该促进性对话中,GAC 与 GNSO 提及了某些具体事项,即:

      1. 与保护域名系统中的国际红十字运动(下称“红十字运动”)相关标识符有关的公共政策考量;
      2. GAC 之所以为与红十字运动及其各个组织最密切相关的术语寻求永久保护,是基于国际公约法律和多部国家法律对“红十字会”、“红新月会”、“红狮子和太阳会”以及“红水晶”名称的保护;
      3. 国家红十字会和红新月会名称列表列出了一组数量有限的、受红十字运动认可的国家红会的具体名称 (http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf)。
      4. 这些术语没有其他合法用途;并且
      5. 在完成 GNSO PDP 后,GAC 已通过其 2014 年 3 月发布的新加坡公报,就请求为红十字运动名称的具体列表中有限数量的名称提供永久保护进行了说明 (https://gacweb.icann.org/download/attachments/28278854/Final%20Communique%20 %20Singapore%202014.pdf?version=1&modificationDate=1397225538000&api=v2)。

      鉴于在 GAC 与 GNSO 讨论后,ICANN 董事会请求 GNSO 理事会考虑启动 GNSO 流程,以便修订 GNSO 以前提出的与以六种联合国官方语言表述的国家红十字会、国际红十字委员会及红十字会与红新月会国际联合会的全名以及为这些名称定义的一组数量有限的变体有关的政策建议 (https://www.icann.org/resources/board-material/resolutions-2017-03-16-en#2.e.i)。

      鉴于 2017 年 5 月,GNSO 理事会通过决议,重新组建原来的 PDP 工作组来考虑董事会的请求 (https://gnso.icann.org/en/council/resolutions#20170503-071)。

      鉴于 2018 年 8 月,重新组建的 PDP 工作组向 GNSO 理事会提交了六条在工作组内达成全面共识的建议 (https://gnso.icann.org/en/issues/igo-ingo/red-cross-protection-policy-amend-process-final-06aug18-en.pdf),包括为根据拟定的共识性政策保留的红十字会和红新月会名称定义的一组数量有限的变体 (https://gnso.icann.org/en/issues/igo-ingo/red-cross-identifiers-proposed-reservation-06aug18-en.pdf)。

      鉴于 2018 年 9 月,GNSO 理事会一致投票决定批准所有 PDP 共识性建议 (https://gnso.icann.org/en/council/resolutions#20180927-3),并于 2018 年 10 月进一步批准向 ICANN 董事会提交建议报告 (https://gnso.icann.org/en/council/resolutions#20181024-1)。

      鉴于根据《ICANN 章程》的要求于 2018 年 11 月开放了公共评议期,以便公众有合理的机会在董事会采取行动之前就拟定的共识性政策提出意见,并便于 GAC 及时就任何公共政策疑虑提出建议。

      鉴于董事会考虑了 GNSO 的建议和与此事项有关的所有其他相关材料。

      兹此发布第 2019.01.27.19 号决议:董事会特此采纳重新组建的国际政府间组织 (IGO) 和国际非政府间组织 (INGO) PDP 工作组提出的并由 GNSO 理事会于 2018 年 9 月 27 日一致投票通过的最终建议。

      第 2019.01.27.20 号决议:董事会指示总裁兼首席执行官或其授权指定人员为采纳的建议制定并执行实施规划(包括费用和时间表),以便与《ICANN 章程》附录 A 保持一致,且符合董事会于 2015 年 9 月 28 日批准的实施审核小组的方针和原则(见 https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f),并继续就此项工作与社群进行沟通。

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

      第 2019.01.27.19 – 2019.01.27.20 号决议的理由

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

      GNSO 启动了 PDP(于 2013 年 11 月结束),就保护与红十字会和红新月会运动有关的某些标识符考虑并提出了某些政策建议。董事会于 2014 年 4 月采纳了与 GAC 针对相关主题(即,关于特定术语“红十字会”、“红新月会”、“红水晶”以及“红狮子和太阳会”)提出的建议相一致的 GNSO 建议 (http://www.icann.org/en/groups/board/documents/resolutions-30apr14-en.htm#2.a)。在 ICANN 组织和社群志愿者完成实施工作后,根据于 2018 年 1 月生效的共识性政策,这四个以联合国六种官方语言表述的特定术语现在未在 DNS 的顶级和二级域中进行授权。

      董事会未批准 GNSO 于 2013 年提出的与其他红十字会和红新月会标识符(即所有国家红十字运动会、国际红十字会和红新月会运动、红十字国际委员会以及红十字会与红新月会国际联合会的国家红会的全名)有关的剩余政策建议。董事会当时未批准这些政策建议,是为了便于董事会、GNSO、GAC 与社群就 GNSO 政策建议与 GAC 建议之间的分歧展开进一步讨论。接下来的几个月中,董事会敦促这些团体之间就可能的解决方式展开了对话。在 2017 年 3 月 GAC 与 GNSO 之间的促进性对话结束后,GNSO 理事会重新组建了原来的 PDP 工作组,考虑对其以前提出的与这些特定标识符有关的建议做出可能的修改。

      2018 年 9 月,GNSO 理事会一致批准在 PDP 工作组最终报告中提交的经过修改的政策建议。GNSO 理事会一致批准经过修改的政策建议后,董事会当前正采取行动,根据《ICANN 章程》规定的流程采纳经修订的共识性政策建议。

      正在处理的提案是什么?

      PDP 建议是,不在 DNS 的二级域中授权以联合国所有六种官方语言表述的某些特定的红十字会和红新月会名称以及经过商定后确定允许使用的这些名称的一系列变体。PDP 建议提供了具体的书面流程和标准,以便纠正在商定的名称和变体列表中发现的错误,以及在该列表中增加或删除条目。采纳的政策将补充与在顶级和二级域中保护以联合国所有六种官方语言表述的术语“红十字会”、“红新月会”、“红水晶”和“红狮子和太阳会”有关的现有共识性政策。

      为清楚起见,PDP 建议不包括保护与国际红十字运动相关的特定缩写词的提案,这仍然是最初的 2013 年 GNSO PDP 未解决的问题,从而导致 PDP 建议与 GAC 就这些缩写词提供的建议不一致。

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

      重新组建的 PDP 工作组按照 GNSO PDP 手册和工作组指南(包括与广泛的社群代表性相关的条款)执行了其工作。工作组的成员由 GNSO 和 ICANN 社群各个部分的代表(包括红十字会的代表)组成。工作组的初步报告于 2018 年 6 月发布以征询公众意见,随后,工作组在提出其最终建议时考虑了收到的所有意见,工作组对所有这些建议达成了全面共识。在 GNSO 理事会就最终报告进行投票之前,工作组主席与就拟议建议表达了一些顾虑的社群成员召开了会议。2018 年 9 月,GNSO 理事会一致投票批准所有建议。

      GNSO 理事会批准的政策建议于 2018 年 11 月发布以征询公众意见,并向 GAC 通知了理事会的行动。

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

      就言论自由提出的可能顾虑涉及以下方面:在 DNS 的二级域中保留红十字会和红新月会名称,以及工作组制定在列表中增加新名称和变体的标准和流程,而不是建议采用固定列表。此外,社群还要求对实施拟定政策的机制(即是否需要修订 ICANN 组织与其签约方签订的合同)做出说明。董事会理解,工作组认为它在提出其最终共识性政策建议时解决了这些问题。

      其他社群意见支持拟定的政策,表示公共政策需要为红十字会提供足够的保护,以防止滥用其名称和认可的变体,并且提供保护的建议是依据国际人道主义法律和多部国家法律提出的。

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

      董事会审核了工作组的最终报告和建议受保护的红十字会名称列表(https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-protection-policy-amend-process-final-06aug18-en.pdfhttps://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-identifiers-proposed-reservation-06aug18-en.pdf)、GNSO 理事会的建议报告 (https://gnso.icann.org/en/drafts/reconvened-red-cross-recommendations-14oct18-en.pdf)、收到的公众意见摘要 (https://www.icann.org/en/system/files/files/report-comments-red-cross-names-consensus-policy-04jan19-en.pdf) 以及与此主题有关的 GAC 建议 (https://gac.icann.org/)。

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

      建议是根据《ICANN 章程》附录 A 中所述的 GNSO 政策制定流程提出的,已在工作组中达成全面共识并且已获得 GNSO 理事会的一致支持。如《ICANN 章程》(附录 A 第 9.a 款)所述,“董事会应采纳由 GNSO 绝对多数票批准的任何 PDP 建议,除非董事会有超过三分之二 (2/3) 的董事会成员投票决定此类政策建议不符合 ICANN 社群或 ICANN 的最佳利益。”

      《章程》还允许就董事会采纳提议的政策后可能会引起的公共政策问题征询 GAC 的意见。在此背景下,GAC 在 2018 年 10 月发布的巴塞罗那公报中表示希望董事会采纳 GNSO 的建议。

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

      董事会采纳这些建议将解决自 2013 年以来一直未解决的问题,即与这些特定红十字会和红新月会名称有关的 GAC 建议与 GNSO 先前的政策不一致的问题。这意味着,董事会此前就这些名称提供的临时保护将被生效后的共识性政策所取代,这就向 ICANN 签约方和一般会员社群更清楚地说明了为这些名称提供保护的范围。

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

      除了在实施采纳的政策期间可能出现的任何财务或其他资源成本外,预计不会对 ICANN、社群或公众产生任何财务影响或后果。

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

      实施 PDP 建议不会直接导致与 DNS 相关的安全性、稳定性或弹性问题。

      这是属于 ICANN 支持组织内部定义的政策流程,还是属于需要(或不需要)征询公众意见的 ICANN 组织管理职能决策?

      按照《ICANN 章程》和 GNSO 运营程序的定义和规定,此事项与 GNSO 的政策流程有关。在执行这些流程的过程中,已满足了所有公众意见征询要求。

    5. 董事会委员会成员和领导层变动

      董事会治理委员会主席贝基·伯尔介绍了此议程事项。董事会副主席兼董事会问责机制委员会 (BAMC) 现任主席克里斯·狄思潘解释称,提议的 BAMC 领导层变动是 BAMC 继任规划工作的一部分。克里斯表示,他将在里昂·桑切斯担任 BAMC 主席这一新职位时根据需要为其提供指导,确保领导层的顺利交接。克里斯称,董事会承诺在就继任规划进行持续讨论期间促进其董事会委员会领导层的顺利交接。克里斯鼓励其他董事会委员会采取措施制定继任规划,以便在必要时,委员会有人可以接任委员会主席职务。

      主席对贝基和克里斯推动这些变动表示感谢,指出对董事会来说,这是非常有益的行动。

      里昂和马修·希尔斯感谢董事会提供此机会。

      萨拉·多伊奇提出动议并得到里昂的支持。随后,主席发起投票,董事会采取了以下行动:

      鉴于克里斯·狄思潘是董事会成员和董事会问责机制委员会 (BAMC) 的现任主席。

      鉴于里昂·桑切斯是董事会的现任成员和 BAMC 的成员。

      鉴于为了促进 BAMC 领导层的顺利交接,董事会治理委员会 (BGC) 建议董事会立即将里昂·桑切斯任命为 BAMC 的主席,并保留狄思潘先生在 BAMC 的成员身份。

      鉴于马修·希尔斯表示有兴趣成为董事会组织效率委员会 (OEC) 的成员,BGC 建议董事会立即将希尔斯先生任命为 OEC 成员。

      兹此发布第 2019.01.27.21 号决议:董事会任命里昂·桑切斯为 BAMC 主席并保留克里斯·狄思潘在 BAMC 的成员身份,任命即刻生效。

      第 2019.01.27.22 号决议:董事会任命马修·希尔斯为 OEC 成员,任命即刻生效。

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

      第 2019.01.27.21 – 2019.01.27.22 号决议的理由

      董事会承诺在就继任规划进行持续讨论期间促进其董事会委员会领导层的顺利交接。为此,董事会问责机制委员会 (BAMC) 已建议其现任主席克里斯·狄思潘辞去主席职务(但仍保留成员身份),并建议董事会任命里昂·桑切斯为 BAMC 主席。作为 BAMC 成员,狄思潘先生将在交接期间与桑切斯先生合作。

      由于董事会治理委员会 (BGC) 接到了推荐委员会的任务,BGC 讨论了 BAMC 的提案,并建议董事会任命里昂·桑切斯为 BAMC 的新主席同时保留狄思潘先生的 BAMC 成员身份,立即生效。董事会同意 BGC 的建议。

      董事会还承诺依照董事会委员会及领导层遴选程序促进董事会委员会的组建工作。BGC 考虑了马修·希尔斯表达的加入董事会效率委员会的意愿,并建议董事会批准此项任命。董事会同意 BGC 的建议。

      这项行动符合公共利益并进一步推进了 ICANN 的使命, 因为董事会委员会在根据《ICANN 章程》和委员会的章程履行董事会指派的任务时,重要的是要具备适当的继任计划,以确保委员会中的领导连续性。而且,依照董事会委员会及领导层遴选程序确定董事会委员会的成员构成也同样重要。这项行动不会对组织产生财务影响,并且不会对域名系统的安全、稳定与弹性产生负面影响。

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

    6. 对重审请求 16-11 的考量:Travel Reservations SRL、Famous Four Media Limited(及其子公司申请人 dot Hotel Limited)、Fegistry LLC、Minds + Machines Group Limited、Spring McCook, LLC 和 Radix FZC(及其子公司申请人 dot Hotel Inc.)(.HOTEL)

      克里斯·狄思潘介绍了此议程事项。贝基·伯尔表示由于存在潜在冲突,他将不参与考虑此事项。克里斯指出,董事会已花费了大量时间考虑请求 16-11 和所有相关材料。

      里昂·桑切斯提出议案并得到丹科·杰夫托维克的支持。随后,主席发起投票,董事会采取了以下行动:

      鉴于 Travel Reservations SRL、Fegistry LLC、Minds + Machines Group Limited 和 Radix FZC(及其子公司申请人 dotHotel Inc.)(统称“请求者”)针对 .HOTEL 提交了标准申请,该申请与其他 .HOTEL 申请一起被归入一个字符争用集。另一位申请人 HOTEL Top-Level-Domain S.a.r.l.(HTLD) 提交了 .HOTEL 的社群申请。

      鉴于 HTLD 参加了社群优先评估 (CPE) 并获得通过。

      鉴于 2016 年 8 月 9 日,董事会通过了第 2016.08.09.14 和 2016.08.09.15 号决议(下称“2016 年决议”),指示 ICANN 组织继续处理 HTLD 针对 .HOTEL gTLD 提交的获通过的社群申请(下称“HTLD 申请”)。

      鉴于请求者提交了重审请求 16-11,寻求重审 2016 年决议。

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

      鉴于 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 邀请请求者为支持请求 16-11 向 BAMC 进行电话介绍,请求者于 2018 年 7 月 19 日进行了电话介绍。BAMC 还邀请请求者提交其他书面材料来回应 CPE 流程审核报告。

      鉴于 BAMC 已仔细考量请求 16-11 的益处和所有相关材料,并已建议否决请求 16-11,因为董事会采纳 2016 年决议时依据的是准确而完整的信息。BAMC 也建议董事会否决请求 16-11,因为没有证据支持请求者提出的主张,即董事会未考虑 HTLD 因门户网站配置而获得的“不公平优势”,也没有证据表明董事会歧视请求者。

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

      兹此发布第 2019.01.27.23 号决议:董事会采纳 BAMC 关于请求 16-11 的建议

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

      第 2019.01.27.23 号决议的理由

      1. 简要概述和建议

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

        2018 年 11 月 16 日,BAMC 评估了请求 16-11 和所有相关材料,并建议董事会否决请求 16-11,因为董事会通过 2016 年决议时依据的是准确而完整的信息。BAMC 也建议董事会否决请求 16-11,因为没有证据支持请求者提出的主张,即董事会未考虑 HTLD 因门户网站配置而获得的“不公平优势”,也没有证据表明董事会歧视请求者。

        2018 年 11 月 30 日,请求者针对 BAMC 建议提交了反驳意见(下称“反驳意见”)。董事会表示,反驳意见未根据适用于请求 16-11 的《章程》条款提交,提交请求 16-11 时生效的 2016 年《章程》中对此做出了规定。2尽管如此,董事会考虑了请求者的反驳意见中的论据,并认为基于下文说明的原因,它们不支持重审。

      2. 问题

        问题是董事会在采纳 2016 年决议时是否:(i) 未考虑实质性信息;或 (ii) 依据的是错误或不准确的实质性信息。

        这些问题将依照提交请求 16-12 时生效的重审请求的相关标准进行考虑。BAMC 建议详细讨论了这些标准。

      3. 分析和理由

        1. 董事会是在考虑了所有实质性信息后才通过 2016 年决议的,并且依据的不是错误或不准确的实质性信息。

          请求者认为重审 2016 年决议具有合理依据,因为 ICANN 组织未正确调查门户网站配置,并且未处理与门户网站配置有关的涉嫌行为。具体来说,请求者声称 ICANN 组织未核实德克·克里谢诺夫斯基 (Dirk Krischenowski) 的声明,此人的凭证被用于访问新 gTLD 门户网站的其他授权用户的保密信息,他宣称自己没有也不会向 HTLD 或其员工提供其访问的信息。BAMC 最终认定并且董事会同意,此论据无法支持重审,因为请求者未确定董事会依据的任何错误或误导性信息,或董事会在通过 2016 年决议时未能考虑的与门户网站配置相关的实质性信息。

          首先,BAMC 裁定并且董事会同意,ICANN 组织对门户网站配置和请求者提出的与门户网站配置有关的问题进行了仔细、全面的分析。调查结果已与 ICANN 董事会分享,董事会在通过 2016 年决议时仔细审议了该结果。BAMC 认为,在调查过程中,ICANN 组织未披露任何证据表明:(i) 克里谢诺夫斯基先生利用门户网站问题获取的信息被用于支持 HTLD 的申请;或 (ii) 克里谢诺夫斯基先生获取的任何信息使得 HTLD 的申请能够通过 CPE。而且,ICANN 的调查发现,在克里谢诺夫斯基先生访问保密信息时,他并未作为授权联系人或股东、高级职员或董事与 HTLD 的申请直接关联。相反,克里谢诺夫斯基先生拥有 HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin) 50% 的股份并担任常务董事,后者是 HTLD 的少数 (48.8%) 股东。HTLD 的唯一常务董事菲利普·格拉本 (Philipp Grabensee) 先生告知 ICANN 组织,克里谢诺夫斯基先生“不是 HTLD 员工”,但在 2012 年提交申请时,克里谢诺夫斯基先生担任 HTLD 申请的顾问。格拉本 (Grabenesee) 先生进一步证实,HTLD“仅在 ICANN 调查期间于 2015 年 4 月 30 日了解到[克里谢诺夫斯基先生访问了数据]”。格拉本先生表示,HTLD 与克里谢诺夫斯基先生之间的业务咨询服务关系已于 2015 年 12 月 31 日终止。3

          其次,与请求者的主张相反,BAMC 裁定,ICANN 组织确实核实了克里谢诺夫斯基先生的声明,即他和他的同事没有也不会与 HTLD 分享他们通过门户网站配置访问的保密信息。HTLD 还向 ICANN 组织确认,其未收到克里谢诺夫斯基先生或其同事通过门户网站配置获得的任何保密信息。如 2016 年决议的理由中所述,董事会在采纳决议时考虑了此信息。4正如董事会在 2016 年决议的理由中陈述的那样,即使克里谢诺夫斯基先生(或其同事)获得了属于请求者的敏感商业文件,这也不会对 HTLD 申请的 CPE 流程造成任何影响。请求者未说明属于其他 .HOTEL 申请人的保密文件如何影响 CPE 标准,CPE 未考虑其他实体的保密信息。虽然克里谢诺夫斯基先生访问信息发生在 2014 年 6 月发布 CPE 报告之前,但 HTLD 并未设法在 CPE 期间修订其申请,也未提交任何本可以由 CPE 小组考量的文件。5没有证据表明 CPE 小组在 CPE 流程期间与克里谢诺夫斯基先生有任何接触,因此,没有任何理由认为 CPE 小组收到了克里谢诺夫斯基先生获得的保密信息。6

          基于这些原因(在 BAMC 建议和本文引用的参考资料中进一步讨论),BAMC 裁定并且董事会同意,请求者未确定董事会依据的任何错误或误导性信息,或董事会在通过 2016 年决议时未能考虑的与门户网站配置相关的实质性信息。董事会允许继续处理 HTLD 申请的决定是在进行全面调查后做出的,具有正当理由并且符合 ICANN 组织的《设立章程》和《章程》。特别是,在做出不应排除 HTLD 申请的决定时,董事会仔细考虑了 ICANN 组织对门户网站配置进行的司法审查和调查的结果,以及请求者关于门户网站配置对 HTLD 申请的 CPE 产生影响的主张。

        2. 董事会在接受 Despegar IRP 小组的声明时依据的不是错误或误导性信息。

          虽然请求 16-11 对董事会与 2016 年决议有关的行为提出质疑,但请求者似乎也对董事会接受 Despegar IRP 小组的声明表示质疑。特别是,请求者声称,“Despegar 等IRP 小组依据的是错误或不准确的实质性信息”,因此,“在 ICANN 董事会接受 Despegar 等IRP 声明时,它依据了相同的错误且不准确的实质性信息”。7

          首先,董事会认同 BAMC 的结论,即请求者的主张已失时效。董事会关于 Despegar IRP 小组声明的决议于 2016 年 3 月 10 日发布。8请求 16-11 于 2016 年 8 月 25 日提交,在董事会接受 Despegar IRP 小组声明后五个多月,这远远超出了当时为重审董事会行动设定的 15 天的时间限制。9

          1. 请求者提出的有关 Dot Registry 和 Corn Lake IRP 小组声明的申诉不支持他们的歧视申诉。

            即使请求者及时对董事会关于 Despegar IRP 小组声明的决议提出质疑,董事会仍然同意 BAMC 的观点,即请求者的申诉无法支持重审。请求者引述在 Dot Registry, LLC 诉 ICANN 案 中发布的 IRP 小组声明(Dot Registry IRP 小组声明)来支持其申诉:Despegar IRP 小组声明“依据的是一个错误前提,即 [CPE 提供商] 的决定被假定为最终决定,并且是由 [CPE 提供商] 独立做出的,而 ICANN 未积极参与”。10特别是,请求者声称 Dot Registry IRP 小组声明证实“ICANN 确实与确定单个 CPE 的评分的评估人进行了通信”,11因此,在判定 ICANN 组织为胜诉方时,Despegar IRP 小组依据的是错误信息(即 ICANN 组织在其对 2014 年 DIDP 请求的回复中表示,ICANN 组织未与参与 CPE 评分的评估人进行通信 — 这是请求 14-39 的主题)。因此,请求者认为 ICANN 董事会在接受 Despegar IRP 小组声明时依据的也是错误信息。请求者还辩称,他们与 Dot Registry 申诉人“情况相似”,因此,如果董事会在为 Dot Registry 申诉人提供救济时拒绝为请求者提供救济,那么,董事会就对请求者存在歧视,这违反了 ICANN 的《设立章程》和《章程》。BAMC 最终认定并且董事会同意,基于以下原因,Dot Registry IRP 声明和董事会对该声明的回复并不支持请求者的重审请求。

            首先,与请求者的论断相反,Dot Registry IRP 小组未发现 ICANN 组织与参与 CPE 评分的 CPE 评估人进行了通信。其次,不能仓促地将一个 IRP 小组做出的声明应用于一个完全独立的、不相关的不同 IRP。Dot Registry IRP 关注的是 .LLC、.INC 和 .LLP,而 Despegar IRP 关注的却是 .HOTEL。每个 IRP 会根据不同相关方就不同申请和不相关的事实情况提供的不同论据,考虑不同的问题。因此,请求者试图将 Dot Registry IRP 声明的结论应用于 Despegar IRP,这种做法没有任何支持依据。

            同样,BAMC 最终认定并且董事会同意,虽然请求者引述董事会接受了在 Corn Lake, LLC 诉 ICANN 案中做出的最终声明(Corn Lake IRP 声明)并决定“对最终审核程序延期,以加入对 Corn Lake 的 .CHARITY 专家裁决的审核”12,但这并不支持重审。与 Dot Registry IRP 一样,Corn Lake IRP 中的情况以及董事会随后就 .CHARITY 做出的决定涉及不同的事实并根据 Corn Lake 申请的具体情况做出了不同的考虑。因此,不可将董事会的行动视为不一致或歧视性对待;相反,这举例说明了董事会必须“识别不同 [gTLD] 申请之间微妙的差异”13并遵守 ICANN 的《设立章程》和《章程》。

          2. CPE 流程审核确认,就已执行的 CPE 而言,ICANN 组织未对 CPE 提供商施加任何不当影响。

            BAMC 最终认定并且董事会同意,请求者关于 ICANN 组织对 CPE 提供商执行 CPE 施加了不当影响的说法不能作为重审依据。14确实,如 BAMC 正确指出的那样,董事会已在 2018 年决议中驳斥了此论据。15

            简言之,CPE 流程审核的范畴 1 报告确认“没有证据显示 ICANN 组织在 CPE 提供商提交的 CPE 报告方面对 CPE 提供商施加了任何不当影响,或不当参与了 CPE 流程”,包括与 HTLD 申请有关的 CPE 流程。16请求者认为范畴 1 报告证实“CPE 提供商并不独立于 ICANN。ICANN 在 CPE 中施加的任何影响都与政策不符,因此属于不当影响。”17请求者未指出他们参照了哪些“政策”,但无论如何,他们不同意范畴 1 报告的结论无法支持重审。这是因为,当 ICANN 组织向 CPE 提供商提出意见时,该意见并不涉及质疑 CPE 提供商的结论,而是为了确保 CPE 报告清楚明白并且“CPE 提供商的结论”— 而非 ICANN 组织的结论 —“有充分的论据支持”,关于这一点请求者并未提出质疑。18请求者还引述“ICANN 与 CPE 提供商为了讨论‘各种问题’进行了通话”,声称那些通话“证实 CPE 提供商并非不会受到 ICANN 组织的外部影响”,因此并不独立。19这些事实均无法证实 CPE 提供商“不独立”或 ICANN 组织对 CPE 提供商施加了不当影响。相反,这些类型的通信表明,通过致力于确保 CPE 提供商的结论清楚无误并且理据充分,而不是指示 CPE 提供商达成特定的结论,ICANN 组织保护了 CPE 提供商的独立性。因此,此论据无法支持重审。所以,BAMC 最终认定并且董事会同意,由于范畴 1 报告表明 ICANN 组织未对 CPE 提供商和 CPE 流程施加不当影响,它驳回请求者关于“向 Despegar 等IRP 小组提供了不完整、误导性信息”的申诉,因为该申诉仅仅是根据 ICANN 组织对 CPE 流程施加了不当影响这一假设提出的。20

          3. 请求者未证实 ICANN 组织有义务出示 ICANN 组织与 CPE 小组之间的通信。

            董事会赞同 BAMC 关于重审没有正当理由的结论,因为正如请求者所声称的那样,Despegar IRP 小组未命令 ICANN 组织出示 ICANN 组织与 CPE 提供商之间的通信文件。BAMC 表示,在 Despegar IRP 中,IRP 小组未命令 ICANN 组织出示任何文件,更不用说出示反映 ICANN 组织与 CPE 小组之间通信的文件了。而且,没有任何政策或程序要求 ICANN 组织在 Despegar IRP 期间或之后自愿出示文件。21相反,在 Dot Registry IRP 期间,Dot Registry IRP 小组命令 ICANN 组织出示反映“ICANN 考量 [CPE 提供商] 执行的与 Dot Registry 申请相关的工作”以及“ICANN 就 [CPE 提供商] 执行的与 Dot Registry 申请相关的工作采取的行动和做出的决定”的所有文件。22ICANN 组织与 .INC、.LLC 和 .LLP CPE 小组之间的通信属于此类请求的范围,因此出示了这些文件。最终,在这两种情形下,ICANN 组织依照适用的政策和程序(包括《ICANN 章程》)采取了行动。23

          4. 请求者未证实对 HTLD 的申请执行新的 CPE 是适当的。

            在未确定特定 CPE 标准的情况下,请求者要求董事会“确保对有关 .hotel 的 CPE 进行有意义的审核,确保采用一致的方法来处理 Dot Registry [IRP 小组声明]”。24BAMC 裁定并且董事会同意,关于请求者声称 HTLD 申请的 CPE 分析结果与其他 CPE 申请不一致,CPE 流程审核的范畴 2 报告已驳斥了这一论据。“FTI 未发现表明 CPE 提供商的评估流程或报告与适用指南有任何背离的证据;FTI 也没有发现 CPE 提供商以不一致的方式应用 CPE 标准的任何实例。”25此外,基于上文讨论以及 BAMC 建议中详细说明的原因,董事会认为,.HOTEL CPE 和 2016 年决议均未表明请求者受到不一致或歧视性对待。基于这些原因,此论据无法支持重审。

        3. 2018 年决议符合 ICANN 的使命、承诺、核心价值和既定 ICANN 政策。

          请求者对 2018 年决议的批评主要涉及 CPE 流程审核的透明度、方法和范围。这些都无法支持重审。BAMC 确定并且董事会同意,BAMC 和董事会在其关于请求 18-6 的建议26(董事会于 2018 年 7 月 18 日采纳该建议27)中解决了请求者就 2018 年决议提出的疑问。BAMC 和董事会在其关于请求 18-6 的决定中给出的理由通过引用的方式纳入本文。

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

          首先,请求 16-11 是依照 2016 年 2 月 11 日《章程》(参见前面的讨论)提交的,其中并不要求就 BAMC 建议提交反驳意见。28尽管如此,董事会考虑了请求者的反驳意见,并认为请求者未提供任何其他支持重审的论据或事实。

          1. 2016 年 2 月 11 日《章程》适用于请求 16-11。

            请求者声称,董事会应根据 ICANN 组织 2018 年 6 月 18 日的《章程》(即提交 BAMC 建议时有效的《章程》版本)中规定的重审标准考量请求 16-11,而不是依照 2016 年 8 月 25 日提交请求 16-11 时有效的 2016 年 2 月 11 日《章程》版本。但是,在请求者提交请求 16-11 时,2018 年 6 月 18 日《章程》并不存在,而且,在批准 2018 年 6 月 18 日版本的《章程》时,董事会未提出进行追溯处理;因此,2018 年 6 月 18 日《章程》没有追溯效力。确实,请求者提交的重审请求表引用了 2016 年 2 月 11 日《章程》下规定的重审标准,该标准指示请求者,在质疑董事会的行动时,“必须确定在做出决定时存在但董事会未考虑的实质性信息,才能提出重审请求”。(参见请求 16-11,第 8 节,第 7 页。)因此,BAMC 根据请求者提交请求 16-11 时有效的 2016 年 2 月 11 日《章程》正确考量了请求 16-11。

          2. 请求者对《章程》提出的质疑不够及时。

            请求者声称,“[2018 年 6 月 18 日《章程》] 第 4(2)(q) 款的正式要求和此案的情况造成了一种不公正的失衡状态,导致请求者无法以有意义的方式参与重审程序”,因为 BAMC 在请求者通过电话介绍请求 16-11 后“差不多四个月”才发布了一份约 33 页的建议,然而(根据现行《章程》),反驳意见必须在 BAMC 发布其建议后 15 天内提交,并且不得超过 10 页。(反驳意见,第 1 页。)如上所述,有效的《章程》版本并未规定请求者有提交反驳意见的权利,因此重审没有正当理由,因为请求者明显不同意现行(不适用)版本的《章程》下适用于提交反驳意见的最后期限。29而且,请求者已经以有意义的方式参与了重审流程:请求者在电话听证会上介绍了请求 16-11(反驳意见,第 1 页);同时,如 BAMC 建议中所述,请求者提交了 — 并且 BAMC 考虑了 — 支持请求 16-11 的七封信函。30当前,请求者还为支持请求 16-11 提交了反驳意见,董事会已考虑该反驳意见。因此,请求者未证实他们无法“有意义地”参与重审请求流程。

          3. 董事会在采纳 2016 年决议时考虑了奥麦尔 (Ohlmer) 女士的行动。

            请求者声称,在处理门户网站配置问题时,“董事会忽略了[凯特琳]·奥麦尔 (Katrin Ohlmer) 所担任的职务”(反驳意见,第 3 页)。请求者声称,在访问其他申请人的保密信息时,奥麦尔女士担任 HTLD 的 CEO,而且,自 HTLD 提交 HTLD 申请直到 2016 年 3 月 23 日,她始终担任 CEO 职务。(请求 16-11,第 8 节,第 19 页;另请参见反驳意见,第 3 页。)请求者声称,由于奥麦尔女士在 HTLD 中任职,她访问的信息“必然会提供给 HTLD”。(反驳意见,第 4 页。)请求者还声称,“HTLD 承认,[奥麦尔女士] (i) 原则上负责代表 HTLD”,(ii) 积极参与了组织 [HTLD 申请] 并为其提供支持的流程,并且 (iii) 负责 HTLD 的日常业务运营。”31

            董事会认为,此论据无法支持重审,因为在采纳 2016 年决议时,董事会确实考虑了奥麦尔女士与 HTLD 的隶属关系。确实,第 2016.08.09.14 – 2016.08.09.15 号决议的理由指出:(1) 奥麦尔女士是克里谢诺夫斯基先生的同事;(2) 奥麦尔女士的全资公司收购了克里谢诺夫斯基先生的全资公司持有的 GmbH Berlin(它是 HTLD 的少数 [48.8%] 股东)股份;并且 (3) 奥麦尔女士(与克里谢诺夫斯基先生一样)“向 ICANN [组织] 保证,[她]将删除或销毁获得的所有信息,并确认[她]没有也不会使用获得的信息,或是将其转发给任何第三方”。32如 BAMC 在其建议中所述,格拉本先生确认 GmbH Berlin 会将其在 HTLD 中的所有权权益转让给另一家公司 Afilias plc。一旦进行转让,奥麦尔女士的公司就不会持有 HTLD 的所有权权益。33

          4. 请求者关于 HTLD 和克里谢诺夫斯基先生做出的保证以及 HTLD 与克里谢诺夫斯基先生之间关系的论据无法支持重审。

            董事会认为,请求者提出的以下论据无法支持重审:董事会不应接受格拉本或克里谢诺夫斯基先生就 HTLD 未由于门户网站配置而收到保密信息所做的声明,因为请求者未提供任何 BAMC 尚未在其建议中驳斥的论据或事实。

            同样,董事会最终认定,请求者的以下论据无法支持重审:董事会在通过 2016 年决议时未能考虑 HTLD 与克里谢诺夫斯基先生之间的关系终止的时间。与请求者的论据相反,很明显,董事会在通过决议时考虑了 HTLD 与克里谢诺夫斯基先生之间的关系终止的时间。在 2016 年决议的理由中,董事会在“决议的理由”部分中提及了相同的时间,指出“HTLD 与克里谢诺夫斯基先生之间的业务咨询服务关系已于 2015 年 12 月 31 日终止”并且“克里谢诺夫斯基先生于 2016 年 3 月 18 日卸任 GmbH Berlin 的常务董事”。34请求者不认同董事会得出的关于此时间不支持取消 HTLD 申请的结论,但在没有更多理由的情况下,这种意见不同无法作为重审的依据。

          5. 请求者未就对 HTLD 申请应用特定 CPE 标准提出质疑

            请求者声称 BAMC 做出以下错误结论:请求者“未就对 HTLD 申请应用 CPE 标准或 CPE 提供商针对任何 CPE 标准做出的特定裁决提出质疑”。(反驳意见,第 9 页,引述建议第 1 页。)但是,请求 16-11 或反驳意见既未确定任何 CPE 标准,也未讨论对 HTLD 申请应用特定 CPE 标准。(参见请求 16-11;反驳意见。)请求者只是重申其论据,即 CPE 提供商“不一致、错误地”应用了(未指明的)CPE 标准,且 BAMC 在提出其建议时不应考虑 CPE 流程审核报告。(反驳意见,第9-10 页。)BAMC 在其建议中驳斥了这些论据,董事会采纳了 BAMC 的理由(如同在本文中详细阐述了一样)。

            基于这些原因,董事会最终认定,没有必要进行重审。

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

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

    7. 对重审请求 18-9 的考量:DotKids Foundation (.KIDS)

      克里斯·狄思潘介绍了此议程事项。贝基·伯尔指出自己存在潜在利益冲突,故弃权。艾芙丽·多利亚由于历史和公共利益原因表示弃权,并指出为便于记录,她将提交投票声明。克里斯指出,董事会已花费了大量时间考虑请求 18-9 和所有相关材料。

      主席提出动议,里昂·桑切斯表示支持。随后,副主席发起投票,董事会采取了以下行动:

      鉴于在第 2010.03.12.47 号决议中,作为新 gTLD 项目的一部分,ICANN 董事会“要求各个利益相关方通过其 [支持组织] SO 和 [咨询委员会] AC 进行协作,并成立一个工作组制定可持续的方法,以便为在申请和运营新 gTLD 时需要协助的申请人提供支持”。

      鉴于为响应第 2010.03.12.47 号决议,成立了 SO/AC 新 gTLD 申请人联合支持工作组 (JAS WG)。

      鉴于 2011 年 9 月 13 日,JAS WG 发布其最终报告,提出了结合新 gTLD 项目向“获批受支持的候选人”提供财务和非财务支持的各种建议。

      鉴于在第 2011.10.28.21 号决议中,董事会承诺认真对待 JAS 最终报告,并组建了一个由董事会成员组成的工作组,“在可行的情况下,监督 [JAS 最终] 报告中提出的建议的范围和实施情况”。

      鉴于在第 2011.12.08.01 – 2011.12.08.03 号决议中,董事会批准了董事会工作组制定的 JAS 最终报告实施规划,指示 ICANN 组织根据 2012 年 1 月为启动申请人支持计划 (ASP) 拟定的标准和流程最终确定实施规划,并批准为符合既定标准的申请人支持候选人减免 47,000 美元的费用。

      鉴于请求者 DotKids Foundation 提交了关于 .KIDS 的社群申请,该申请与另一个 .KIDS 申请和 .KID 申请被一起放在字符争用集中。

      鉴于请求者依照 ASP 提出了申请并以减免申请费用的形式获得了经济援助。

      鉴于请求者参与了社群优先评估但并未通过,并安排在 2018 年 10 月 10 日进行 ICANN 拍卖。

      鉴于 2018 年 8 月,请求者联系 ICANN 组织,为参与字符串争用解决流程请求财务支持,ICANN 组织以超出 ASP 范围为由拒绝了该请求。

      鉴于 2018 年 9 月 21 日,请求者提交了重审请求 18-9,寻求重审 ICANN 组织对其为参与字符串争用解决流程而提出的经济援助请求作出的回复。

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

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

      鉴于 BAMC 仔细考虑了请求 18-9 的益处和所有相关材料,并建议否决请求 18-9,因为 ICANN 组织在响应请求者为参与字符串争用解决流程而提出的经济援助请求时遵守了既定政策和程序;ICANN 组织未违反其《章程》中确定的有关全球公共利益的核心价值。

      鉴于 2018 年 12 月 3 日,请求者针对 BAMC 关于请求 18-9 的建议提交了反驳意见

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

      兹此发布第 2019.01.27.24 号决议:董事会采纳 BAMC 关于请求 18-9 的建议

      十四位董事投票支持第 2019.01.27.24 号决议。贝基·伯尔和艾芙丽·多利亚弃权。艾芙丽提供了投票声明。决议通过。

      第 2019.01.27.24 号决议的理由

      1. 简要概述和建议

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

        2018 年 11 月 16 日,BAMC 评估了请求 18-9 和所有相关材料,并建议董事会否决请求 18-9,因为 ICANN 组织在响应请求者为参与字符串争用解决流程而提出的经济援助请求时遵守了既定政策和程序;ICANN 组织未违反其《章程》中确定的有关全球公共利益的核心价值。

        2018 年 12 月 3 日,请求者针对 BAMC 建议提交了反驳意见(下称“反驳意见”)。董事会指出,反驳意见是在《ICANN 章程》第 4 条第 4.2(q) 款规定的期限后提交的。尽管如此,董事会审议了请求者的反驳意见中的论据,并认为基于以下原因,他们无法支持重审。

      2. 问题

        问题如下:

        • 在响应请求者根据 ASP 为参与 .KID/.KIDS 字符争用集的字符串争用解决流程而提出的经济援助请求时,ICANN 组织是否遵循了既定政策;以及
        • ICANN 组织是否遵循了其《章程》中确定的与 ICANN 组织的全球公共利益承诺有关的核心价值。35

        这些问题将依照适用于重审请求的相关标准(参见 BAMC 建议)进行审议。

      3. 分析和理由

        1. ICANN 组织在响应请求者提出的经济援助请求时遵循了既定政策和程序。

          请求者认为重审具有正当理由,因为 ICANN 组织拒绝其为参与争用解决流程而提出的经济援助请求的做法与 JAS 最终报告相矛盾。具体来说,请求者声称 ICANN 组织在考虑 JAS 最终报告时面临“时间压力”,这导致 ICANN 董事会只批准了 JAS WG 提出的为合格申请人减免申请费用的建议,因此,ICANN 董事会当时“未考虑[]”其他部分的建议。36BAMC 裁定并且董事会同意,请求者未提供任何证据来支持 ICANN 董事会未在 2011 年考虑整个 JAS 最终报告这一主张。如 BAMC 建议和本文引用的参考资料详细阐述的那样,ICANN 董事会确实认真而全面地考虑了 JAS 最终报告中提出的所有建议。2011 年 10 月 28 日,ICANN 董事会通过决议,决定“认真”考虑该最终报告并组建了一个由董事会成员组成的工作组,“在可行的情况下监督 [JAS 最终] 报告中提出的建议的范围和实施情况”。37此后,董事会工作组与 JAS WG 任命的社群成员组成的次级小组协作,共同制订流程标准文件,确定了 ASP 的范围和要求,随后,董事会于 2011 年 12 月批准了该 ASP。38

          在依照流程标准文件批准实施规划时,ICANN 董事会并未采纳 JAS 最终报告中的所有建议,尽管如此,这一事实仍无法支持请求者的以下观点:ICANN 组织未考虑(并拒绝了)未实施的建议。首先,没有任何政策或程序要求 ICANN 采纳 JAS 最终报告中提出的所有建议。相反,如 JAS 最终报告中所述,这些建议只是“提交给 GNSO、ALAC、ICANN 董事会和 ICANN 社群考量的”。39ICANN 董事会仍然可以自行决定实施哪些建议(如有),且 ICANN 董事会决定只实施“可行”建议。40

          第 2011.12.08.01 – 2011.12.08.03 号决议的理由也直接驳斥了请求者观点,其中指出,董事会经过考虑并决定采纳 JAS 最终报告中提出的所有建议。“注意:此流程未遵循所有 JAS 建议。”41相反,董事会在其认为可行的情况下,自行决定以“减免 47,000 美元的费用”的形式为合格的申请人支持候选人提供经济援助。42

          BAMC 指出,董事会唯一批准的 JAS 建议是那些在流程标准文件中提出的建议,这反过来定义了 ASP 的范围和要求。所有其他 JAS WG 建议都经过审议但未予以采纳。由于所实施的 ASP 没有规定为争用解决流程提供经济援助,因此,董事会赞同 BAMC 的结论,即 ICANN 组织在拒绝请求者的此类支持请求时未违反任何既定政策或程序。

          请求者也未确定强制要求 ICANN 在当前轮次的新 gTLD 项目中回过头来重新审议先前未采纳的 JAS WG 建议的任何政策或程序(因为没有此类政策或程序)。相反,流程标准文件中提出的 ASP 要求旨在作为“非常明确的要求,它们是申请人支持计划的最终要求”。43

          董事会进一步赞同 BAMC 的结论:即使董事会应请求者的要求“处理剩下的 JAS 最终报告建议”,44重审仍然没有合理依据。BAMC 审核了 JAS 最终报告和相关材料,包括公众意见征询期间收到的意见,并确认 JAS WG 或其他团体都从未建议以请求者要求的方式提供经济援助。因此,即使 ICANN 组织应请求者的要求“处理剩下的 JAS 最终报告建议”,45ICANN 组织也不会在 JAS 最终报告中找到任何要求为参与争用解决流程提供经济援助的建议。

        2. ICANN 组织在响应请求者提出的经济援助请求时遵循了其核心价值。

          董事会认同 BAMC 的结论,即 ICANN 组织拒绝请求者的经济援助请求并未违背其以符合全球公共利益的方式行事的核心价值。请求者引述的核心价值为:

          在各级政策制定与决策的过程中,积极寻求并支持知情前提下的广泛参与,以此彰显互联网在功能、地域和文化方面的多样性,从而确保使用自下而上的多利益相关方政策制定流程来维护全球公众利益,并保证这些流程的可问责性和透明性。46

          ICANN 组织实施 ASP 体现了这一核心价值,而不是像请求者声称的那样违背了该核心价值。2010 年 3 月,ICANN 董事会要求各个利益相关方“通过其 [支持组织] SO 和 [咨询委员会] AC 进行协作,并成立一个工作组制定可持续的方法,以便为在申请和运营新 gTLD 时需要协助的申请人提供支持”,这一要求体现了通过多利益相关方模型“积极寻求并支持知情前提下的广泛参与”的核心价值。47编制 JAS 最终报告(ICANN 董事会已全面考虑了该报告)是为了响应 ICANN 对多利益相关方模型所做的承诺,也是 ICANN 在新 gTLD 项目中履行“维护全球公众利益”的承诺的例证。在决定考虑 JAS 最终报告时,董事会指出其会“认真对待 ICANN 社群的主张,即申请人支持计划将鼓励对新 gTLD 项目的多样化参与,并促进 ICANN 实现扩大多利益相关方模型范围的目标”。48

          BAMC 裁定并且董事会同意,请求者似乎在以对自己有利的方式敦促 ICANN 组织规避适用于 ASP 的要求中规定的既定政策,这会损害而不是保障全球公共利益。ICANN 组织承诺确保多样性、运营稳定性并秉持不歧视原则,但不负责保证向任何特定申请人授权 gTLD。请求者未能证实董事会有任何违背 ICANN 核心价值的行为。

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

          首先,董事会表示反驳意见的提出不够及时。请求者于 2018 年 11 月 17 日收到建议。49反驳意见应在 15 天后,于 2018 年 12 月 2 日提交。50请求者在 2018 年 12 月 3 日提交了反驳意见,超过了最后期限一天 。51尽管如此,董事会审议了请求者的反驳意见中的论据,并认为基于以下原因,它们无法支持重审。

          1. 请求 18-9 旨在寻求对 ICANN 组织拒绝请求者提出的财务支持请求进行重审。

            请求者在反驳意见中辩称,那不是“直接”寻求“资金支持”。(反驳意见,第 1 页。同上,另请参见第 3 页 [请求 18-9“未请求任何特定形式的经济援助”]。)但是,如 BAMC 在建议中所述,2018 年 8 月 27 日,请求者向 ICANN 组织发送电子邮件,表示它“希望为参与字符串争用解决流程请求财务支持”。(BAMC 建议第 9 页,引述建议附录 A。)请求者确认,ICANN 组织对该电子邮件的回复是“拒绝该请求”,因为其寻求采取的行动已经过重审。52因此,BAMC 有理由认为,请求 18-9 旨在寻求对 ICANN 组织拒绝请求者的财务支持请求进行重审。

            现在,请求者声称请求 18-9“只是”要求“ICANN 董事会启动流程来考虑 JAS 最终报告的剩余部分”。(反驳意见,第 1 页。)不管怎样,BAMC 已经考虑了这项请求。BAMC 最终认定,“ICANN 组织确实认真而全面地考虑了 JAS 最终报告中提出的所有建议”。(BAMC 建议,第 13 页。)董事会同意并采纳了 BAMC 建议中给出的理由。

            董事会认为,请求者的反驳意见未提供任何新论据,也未确定任何强制要求 ICANN 考虑先前未采纳的 JAS WG 建议的政策或程序(因为没有此类政策或程序)。

            董事会指出,反驳意见表示不赞同 BAMC 的以下结论:董事会已明确表示它决定不采纳 JAS 最终报告中提出的所有建议。请求者声称,至于董事会是否会进一步考量其未采纳的建议,这“最多只是使这个问题处于未决状态”。(反驳意见,第 2 页)但是,请求者引述的材料中没有任何内容支持请求者的主张,即董事会希望“搁置[]...暂不决定”是否有可能进一步考虑未在 2011 年采纳的 JAS 建议。(反驳意见,第 2 页。)如 BAMC 所述,第 2011.12.08.01 – 2011.12.08.03 号决议和支持材料清楚表明,董事会经审议并决定,除在流程标准文件中提出的建议外,不采纳任何 JAS WG 建议。具体来说,第 2011.12.08.01 号决议指示 ICANN 组织“根据为启动申请人支持计划拟定的标准和流程最终确定实施规划”。53流程标准文件既未对请求者请求的其他资金做出规定,也未提出可能会重新评估董事会未在 2011 年采纳的 JAS 建议。54董事会并未被请求者基于意见提出的相反论据所说服。请求者未提供任何新事实或证据表明重审具有正当理由。

          2. JAS WG 从未建议以请求者寻求的方式提供财务支持。

            在反驳意见中,请求者首次辩称,如果没有获得“某种进一步的支持(例如费用减免、调整、分期或其他方式),申请人支持计划就会完全失去意义”。(反驳意见,第 1 页。)首先,《章程》规定,反驳意见“应...仅限于反驳或驳斥建议中提出的问题”,如果请求者“本应该”在最初提交请求时提供新证据,则此时“不应提供该证据”。55因此,此论据未反驳建议中提出的具体问题。它本应在请求中提出,因而在反驳意见中提出并不合适。而且,对董事会第 2011.12.08.01 – 2011.12.08.03 号决议或 ASP 提出的任何质疑早已超过时效期。尽管如此,董事会考虑了该论据,并基于以下原因,最终认定其不支持重审。

            请求者辩称,BAMC 错误地做出了以下结论:请求者在请求 18-9 中依据的任何 JAS WG 建议均未“特别建议提供财务支持以帮助完成争用解决流程”。(反驳意见,第 3 页。)请求者声称,“即使无法为争用解决流程提供直接支持,调整其他费用也可能”对获批受支持的候选人产生重大影响,且 BAMC 不应得出“正因为可能不包括直接出资...可能已经考虑了其他费用调整”的结论。(同上。)BAMC 的结论不像请求者认为的那样存在限制;BAMC 最终认定,JAS 最终报告不支持为争用解决流程的任何部分提供任何类型的财务支持。(BAMC 建议,第15-16 页。)此外,BAMC 还指出,JAS 最终报告特别指出,在字符串争用的情况下,申请人必须为流程的“这个附加步骤提供资金”。(BAMC 建议,第 16 页,引述 JAS 最终报告第 28 页。)请求者未确定任何政策或程序(也没有此类政策或程序)来要求 ICANN 组织修改或补充 JAS WG 建议,以便在董事会尚未做出此类规定且向董事会提交的报告未建议提供此类支持时向请求者或情况类似的申请人提供其他支持。

            此外,董事会还认为,请求者关于 BAMC 最终认定“任何其他进一步财务支持都无法提供帮助”的论断并不准确。(反驳意见,第 3 页。)BAMC 得出结论,ICANN 组织在做出 ASP 不会为请求者提供其他经济援助的结论时遵循了既定政策和程序。(BAMC 建议,第12-16 页。)

            基于上述原因,请求者的反驳意见未提供任何支持重审的论据。

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

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

    8. 对重审请求 16-12 的考量:Merck KGaA (.MERCK)

      克里斯·狄思潘介绍了此议程事项。克里斯指出,董事会已花费了大量时间考虑请求 16-12 和所有相关材料。

      贝基·伯尔提出动议并得到特里普蒂·辛哈的支持。随后,主席发起投票,董事会采取了以下行动:

      鉴于 Merck KGaA(下称“请求者”)针对 .MERCK 提交了社群申请(下称“申请”),该申请与其他 .MERCK 申请一起被归入一个字符争用集。

      鉴于请求者参加了社群优先评估 (CPE),但并未通过 CPE。

      鉴于请求者提交了重审请求 16-12,寻求对其申请的 CPE 报告以及 ICANN 组织接受该 CPE 报告进行重审。

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

      鉴于 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-12。

      鉴于请求者提交了其他支持材料,并为支持请求 16-12 向 BAMC 进行了电话介绍;请求者还提交了向 BAMC 进行的电话介绍的书面摘要。

      鉴于 BAMC 仔细考虑了请求 16-12 的益处和所有相关材料,并建议否决请求 16-12,因为 CPE 提供商在评估标准 2 时未违反任何既定政策或程序,并且 ICANN 组织接受 CPE 提供商的报告是符合既定政策的。

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

      兹此发布第 2019.01.27.25 号决议:董事会采纳 BAMC 关于请求 16-12 的建议

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

      第 2019.01.27.25 号决议的理由

      1. 简要概述和建议

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

        2018 年 12 月 14 日,BAMC 评估了请求 16-12 和所有相关材料,并建议董事会否决请求 16-12,因为 CPE 提供商在评估标准 2 时未违反任何既定政策或程序,并且 ICANN 组织接受 CPE 提供商的报告是符合既定政策的。

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

      2. 问题

        问题如下:

        • CPE 提供商在 CPE 报告中应用标准 2 — 拟议字符串与社群之间的联系 — 时是否遵循了《指导手册》;
        • ICANN 组织在接受 CPE 报告时是否遵循了适用政策和程序;
        • ICANN 组织是否必须披露 ICANN 组织与 CPE 提供商之间与申请有关的记录信息和通信;以及
        • 董事会在认可并接受 CPE 流程审核报告中的结论时是否遵循了适用承诺、核心价值和政策。

        这些问题将依照提交请求 16-12 时生效的重审请求的相关标准进行考虑。BAMC 建议详细讨论了这些标准。

      3. 分析和理由

        1. CPE 标准和程序

          CPE 是一个争用解决机制,面向将其申请自行指定为社群申请的申请人提供。57《申请人指导手册》(下称“《指导手册》”)第 4 单元第 4.2 节中定义了 CPE 标准和 CPE 流程。接受 CPE 的社群申请将按照以下标准进行评估:标准 1:社群设立;标准 2:拟议字符串与社群之间的联系;标准 3:注册政策;以及标准 4:社群支持。58依照《指导手册》,标准的顺序反映了 CPE 提供商评估这些标准的顺序。一项申请要通过 CPE,必须在四个标准的评分中至少获得 14 分(总分为 16 分),每个标准的最高分为 4 分。通过 CPE 的申请将“排除所有与之直接竞争的标准申请,无论该标准申请多么地符合条件”。59CPE 由 CPE 提供商任命的两名评估人组成的独立小组执行。60CPE 提供商负责确定社群申请是否符合《指导手册》第 4.2.3 单元中规定的四个社群优先标准。61

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

          请求者声称,CPE 提供商判断错误,针对标准 2 将请求者的申请评为零分(总分为四分)。标准 2 评估“字符串与它声称代表的特定社群之间的相关性”。62它是通过两个子标准来衡量的:子标准 2-A“联系”(总分为三分)和子标准 2-B“唯一性”(总分为一分)。63

          1. CPE 提供商在应用子标准 2-A“联系”时遵循了适用政策和程序。

            请求者的申请的子标准 2-A 评分为零分。子标准 2-A 要获得三分,申请的字符串必须“与社群名称一致,或者是社群为人熟知的简写或缩写形式”。64CPE 提供商确定,请求者的申请不符合获得三分的条件,因为申请的字符串“与申请中定义的社群名称不一致,也不是社群为人熟知的简写或缩写形式”。65

            要获得两分,申请的字符串应“准确描述社群或社群成员,而不会远远超出社群的范围”。66此子标准不可能获得一分的评分。此外,CPE 提供商还发现,请求者的申请不符合获得两分的条件,因为申请的字符串未“识别…申请中定义的社群”。67

            CPE 提供商认为

            虽然字符串“Merck”与申请中定义的社群名称一致,但它也与在美国和加拿大运营的另一家名为“Merck”的法人实体的名称一致。这家总部位于美国的公司 Merck & Co., Inc. 涉足制药、疫苗和动物卫生行业,拥有 68,000 名员工,2015 年的收益达 395 亿美元。因此,这是一家也称为“Merck”的大型实体。68

            CPE 提供商据此裁定,该字符串“‘远远超出了定义的社群范围’…因为申请的字符串也识别了一家大型实体 — 在美国和加拿大运营的 Merck — 它不属于申请人定义的社群。”69

            BAMC 认为,虽然请求者不认同 CPE 提供商的结论,但请求者并未确定 CPE 提供商在做出裁决时违反了任何政策或程序。70请求者也未提供任何证据表明 CPE 提供商违反了任何既定政策或程序。BAMC 指出,请求者不否认上述总部位于美国的实体与请求者在申请中定义的社群有关联;相反,请求 16-12 花了大量篇幅概述请求者与总部位于美国的 Merck & Co., Inc.(请求者的前子公司)之间关于哪家公司可以在美国境外使用名称“MERCK”的长达数十年、充满争议的法律纠纷。71因此,BAMC 最终认定并且董事会同意,请求者不同意 CPE 提供商的结论实质上并不能作为重审依据。

            此外,如 CPE 流程审核范畴 2 报告所述,在执行所有 CPE 时,CPE 提供商在依照子标准 2-A 进行分析时遵循了《指导手册》。72

            考量 CPE 提供商对 Merck & Co. 申请的处理后确认,在所有 CPE 中,CPE 提供商都一致地分析了子标准 2-A。在与 Merck & Co., Inc. 提交的 .MERCK gTLD 社群申请有关的 CPE 报告(下称“Merck & Co. CPE 报告”)中,CPE 提供商对 Merck & Co. 申请应用的理由与请求者的 CPE 报告中包含的理由相同:它认为 Merck & Co., Inc. 申请的字符串 (.MERCK) 远远超出了社群的范围,因为这里的请求者是“一个也以‘Merck’命名的大型实体”,它不包含在 Merck & Co. 的 .MERCK 申请中定义的社群之内。73在这方面,CPE 提供商考虑了请求者的存在是否会导致 Merck & Co. 申请在联系要素方面无法获得任何得分。74为此,CPE 提供商针对子标准 2-A 将 Merck & Co. 申请评为零分,与 CPE 提供商对申请人的申请给出的评分相同。75

            请求者声称,其社群的规模要大于与 Merck & Co., Inc. 关联的社群,因此“该字符串明确识别了请求者”76,对此,BAMC 最终认定并且董事会同意,这项主张无法证实,在做出字符串 .MERCK 远远超出请求者的申请中定义的社群范围的结论时,CPE 提供商未能遵循任何既定政策或程序。请求者也无法证实,CPE 提供商在针对联系要素给出零分时未遵循任何政策或程序。相反,BAMC 指出,《指导手册》特别规定,如果字符串远远超出申请中的社群范围,就必须给出零分。

            BAMC 裁定并且董事会同意,虽然请求者认为,对于子标准 2-A,它本应得到更高评分,因为它“将采取所有必要措施(包括地理目标锁定)来避免位于 Merck & Co. 拥有商标权的少数地区中的用户访问互联网”,但这无法作为重审依据,因为请求者未指出要求 CPE 提供商必须(或应当)在对子标准 2-A 评分时考虑地理目标锁定因素的任何政策或程序。BAMC 表示《指导手册》中没有此类政策。

            请求者称,CPE 提供商未考虑 Merck & Co., Inc.“非法入侵”其领域及“非法使用”Merck 一词的证据,77对此,BAMC 最终认定并且董事会同意,CPE 提供商不需要评估请求者与 Merck & Co., Inc. 之间长达数十年的商标纠纷。7879因此,CPE 不考虑该持续存在的法律纠纷并不违反任何既定政策或程序,并且此论据也无法作为重审依据。基于相同的原因,董事会也认同 BAMC 的结论,即 ICANN 组织不需要向 CPE 提供商提供请求者与 Merck & Co., Inc. 之间存在的法律纠纷的相关信息。请求者没有也无法确定任何要求 ICANN 组织向 CPE 提供商提供此类信息的政策或程序。

          2. 对子标准 2-A 的应用与其他 CPE 报告是一致的。

            请求者声称,CPE 提供商在 CPE 报告中对子标准 2-A 的分析与其针对 .ECO、.RADIO、.SPA 和 .ART 申请对同一子标准进行的分析不一致,声称在上述每个案例中,“虽然有其他实体使用相同的名称,但申请人的联系要求得分为三分”。80BAMC 最终认定并且董事会同意,请求者没有为此论断提供支持信息或其他论据,而且该论据也站不住脚。如 BAMC 建议和本文引用的参考资料详细阐述的那样,在上述每个案例中,CPE 提供商确定申请的字符串与社群名称一致,但它识别了社群,而没有远远超出社群的范围。81相反,CPE 提供商认为,.MERCK 确实与社群名称相一致,但它与另一个社群(即总部位于美国的 Merck & Co., Inc.)的名称相一致。82因此,董事会认同 BAMC 的结论,即不能以此为由要求重审,因为请求者未提供任何证据表明 CPE 提供商违反了任何既定政策或程序。

          3. CPE 提供商在应用子标准 2-B“唯一性”时遵循了适用政策和程序。

            BAMC 裁定并且董事会同意,请求者未证实 CPE 提供商在针对子标准 2-B“唯一性”将请求者的申请评为零分时违反了任何政策或程序。子标准 2-B 要获得一分,除识别申请中描述的社群外,申请的字符串还不得具有其他重要意义。83如果一项申请在子标准 2-A 上不符合获得两分或三分的条件,那么,它在子标准 2-B 上也不符合获得一分的条件。84基于以上讨论的原因,CPE 提供商对子标准 2-B 给出了零分,因为申请的字符串在子标准 2-A 上未获得两分或三分的评分。85

            请求者认为,由于请求者长期独家使用其社群名称 MERCK,在唯一性要素上,CPE 提供商对申请的评分应为一分。86与其在子标准 2-A 中的论据类似,董事会赞同 BAMC 的结论,即请求者对 CPE 提供商就子标准进行的评分提出质疑完全是因为其不同意 CPE 提供商的结论,这不能作为重审的理由。关于 CPE 提供商做出的申请的子标准 2-B 评分应为零分的裁定,请求者未证明提供商违反了任何政策或程序。

        3. CPE 报告不涉及正当流程权利。

          请求者辩称,CPE 提供商在起草 CPE 报告时“未采取合理的谨慎态度”,“并错误地应用了 ICANN 在 [指导手册] 中提出的标准和政策,导致剥夺了请求者的正当流程权利”。87董事会赞同 BAMC 的结论,即此论据无法作为重审依据。基于上文讨论并在 BAMC 建议中进一步详细阐述的原因,请求者未证实 CPE 提供商未遵循《指导手册》中为 CPE 制定的任何既定政策和程序。相反,请求者提出,应该有一个对 ICANN 组织的第三方服务提供商(包括 CPE 提供商、合法权利异议小组和字符串混淆小组)做出的决定提出正式申诉的流程。经过广泛的社群磋商并由董事会于 2011 年 6 月采纳的《指导手册》中规定了在 gTLD 争用解决流程中对相关裁决提出质疑的方法。88对《指导手册》提出质疑的时间已经过去很久了。89

          如 BAMC 所述,《指导手册》通过 ICANN 的问责机制为质疑 CPE 流程的结果提供了途径。90确实,请求者已通过对请求 16-12 发起重审流程,行使了这项权利。91因此,董事会认为,因为 CPE 提供商对申请应用标准 2 符合《指导手册》的规定,因此 ICANN 组织接受 CPE 报告也符合适用政策和程序,且没有违反任何“正当流程”。董事会还认为,《指导手册》中不存在有关评估结果基本内容的申诉机制并不算是违反正当流程。

        4. CPE 流程审核支持 Merck KGaA 申请的结果。

          CPE 流程审核范畴 2 报告表明,CPE 提供商在所有 CPE 中一致地应用了 CPE 标准,没有任何证据表明 CPE 提供商的评估流程或报告以任何形式违反了适用指南。92基于此额外的原因,BAMC 认为并且董事会同意,请求者关于 CPE 提供商错误地应用了标准 2 的论据无法支持重审。

          请求者辩称,CPE 流程审核范畴 2 和 3 报告的范围过于狭窄,未重新评估 CPE 提供商对“联系”标准的应用,也未评估 CPE 提供商所进行的调查的适当性或合理性。93基于 BAMC 建议和本文引用的参考资料给出的原因,BAMC 最终认定并且董事会同意,请求者的申诉无法支持重审,因为请求者未证实在此过程中违反了任何流程或程序。(BAMC 建议,第25-28 页。)

        5. 请求者披露记录信息的请求不构成重审依据。

          BAMC 裁定并且董事会同意,请求者有关披露 ICANN 组织与 CPE 提供商之间与申请和 CPE 报告有关的记录信息的请求并未在重审请求的背景下正确提出,因为请求者未要求 ICANN 组织重审董事会或员工的行动或不作为。94因此,董事会同意 BAMC 的结论,即这不构成重审依据。至于请求者希望根据 ICANN 的记录信息披露政策 (DIDP) 提出请求,请求者可以依照 DIDP 单独提出请求。95但是,应当注意的是,请求者试图获取的记录信息是多项 DIDP 请求和随后的重审请求的主题,请求者可以考虑在提交另一项本质上相同的请求之前查看那些请求。96

          基于上述原因,董事会最终认定,重审没有正当理由。

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

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

    9. 其他事务

      未达成任何决议。

    主席之后宣布会议结束。


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

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

3 菲利普·格拉本先生致 ICANN 的信函 (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-23mar16-en.pdf)。请求者声称奥麦尔女士也一直与 HTLD 有关联。参见请求 16-11,第 8 节,第 15 页。董事会在通过 2016 年决议时考虑了此信息。参见第 2016.08.09.14 – 2016.08.09.15 号决议的理由 (https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h)。BAMC 最终认定,奥麦尔女士之前与 HTLD 有关联 — 请求者承认这种关联关系已于 2016 年 6 月 17 日之前终止(请求 16-11,第 8 节,第 15 页)— 并不支持重审,因为没有任何证据表明奥麦尔女士(或克里谢诺夫斯基先生)以不当方式访问的任何保密信息被提供给 HTLD 或导致 HTLD 申请在 CPE 中获得不公平优势。董事会同意此结论。

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

5 支持第 2016.08.09.14 – 2016.08.09.15 号决议的简报材料,第95-96 页 (https://www.icann.org/en/system/files/bm/briefing-materials-2-2-redacted-09aug16-en.pdf)。

6 同上第 95-96 页。

7 同上,第 8 节,第 9 页。

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

9《ICANN 章程》,2016 年 2 月 11 日,第 IV 条第 2.5 款。

10 请求 16-11,第 8 节,第 12 页。

11 同上,(着重号为原文所有)。

12 Crowell and Moring 致 ICANN 董事会信函,2016 年 12 月 28 日,第 4-5 页 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-crowell-moring-to-board-redacted-28dec16-en.pdf)。

13 同上。

14 请求 16-11,第 8 节,第 12-13 页。

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

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

17 Petillion 2018 年 2 月 1 日致 BAMC 信函,第 3 页 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-petillion-to-icann-bamc-redacted-01feb18-en.pdf)。

18 Petillion 2018 年 2 月 1 日致 BAMC 信函,第 3 页,引述 FTI 范畴 1 报告,第 12 页(着重部分由作者标明)。

19 同上。

20 同上,第 3 页。

21《ICANN 章程》、DIDP 或其他政策或程序均不要求 ICANN 在 IRP 过程中自愿出示在响应 DIDP 请求时被适当拒绝的文件。

22 第 3 号程序令,Dot Registry LLC 诉 ICANN 案,ICDR 案件编号 01-14-0001-5004 (https://www.icann.org/resources/pages/dot-registry-v-icann-2014-09-25-en)。

23 请求者完全知晓 ICANN 组织与 CPE 小组之间的通信,因为 CPE 小组流程文件中明确考虑了此类通信,并且 ICANN 在 2014 年 DIDP 响应中披露存在这些通信。参见 CPE 小组流程文件 (https://newgtlds.icann.org/en/applicants/cpe)(“出现问题或需要其他流程信息才能评估申请时,经济学人智库将与 ICANN 进行协作。”)。

24 请求 16-11,第 9 节,第 20 页。

25 范畴 2 报告,第 2 页 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf)。

26 BAMC 关于请求 18-6 的建议 (https://www.icann.org/en/system/files/files/reconsideration-18-6-trs-et-al-bamc-recommendation-14jun18-en.pdf)。

27 第 2918.07.18.09 号决议 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.g)。

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

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

30 参见 https://www.icann.org/resources/pages/reconsideration-16-11-trs-et-al-request-2016-08-25-en(提供信函链接)。

31 同上,引述格拉本致 ICANN 组织的信函,2016 年 5 月 18 日 (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-18may16-en.pdf)。

32 参见第 2016.08.09.14 – 2016.08.09.15 号决议的理由,https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h

33 同上。

34 第 2016.08.09.14 – 2016.08.09.15 号决议的理由,https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h

35 参见重审请求 18-9。

36 重审请求 18-9,第 7 节,第 4 页。

37 2011 年 10 月 28 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2)。

38 2011 年 12 月 8 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1)。

39 JAS 最终报告第 I 页(着重部分由作者标明)(http://dakar42.icann.org/meetings/dakar2011/presentation-jas-final-report-13sep11-en.pdf)。

40 2011 年 10 月 28 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2)。

41 2011 年 12 月 8 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1)。

42 2011 年 12 月 8 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1)。

43 2011 年 10 月 28 日董事会会议记录(着重部分由作者标明)(https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2)。

44 重审请求 18-9,第 7 节,第 4 页。

45 重审请求 18-9,第 7 节,第 4 页。

46《ICANN 章程》,2018 年 6 月 18 日,第 1 条第 1.2(b)(ii) 款。

47 2010 年 3 月 12 日董事会决议 (https://www.icann.org/resources/board-material/resolutions-2010-03-12-en)。

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

49 请求者发送给 ICANN 的电子邮件,2018 年 12 月 3 日,参考资料的附件 __。

50 参见《ICANN 章程》,2018 年 6 月 18 日,第 4 条第 4.2(q) 款(为提交反驳意见设定最后期限)。

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

52 请求 18-9,第 2 节,第 1 页。

53 第 2018.12.08.01 号决议(https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1 [着重部分由作者标明]。)

54 参见流程标准文件,包含在 2011 年 12 月 8 日董事会会议的董事会简报材料中,第 81 和 87 页(共 164 页)(https://www.icann.org/en/system/files/bm/briefing-materials-3-08dec11-en.pdf)。

55《ICANN 章程》,2018 年 6 月 18 日,第 4 条第 4.2(q) 款。

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

57 参见《指导手册》第 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

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

59 同上,第 4 单元,第 4.2.3 节,第 4-9 页。

60 同上,第 4 单元,第 4.2.2 节。

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

62 参见《指导手册》第 4 单元,第 4.2.3 节,第 4-13 页 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf)。

63 同上,第4-12-4-13 页。

64 同上。

65 CPE 报告,第 3 页。

66 同上,第 4-12 页。

67 同上。

68 同上。

69 同上。

70 请求者声称,BAMC 应在针对请求 16-12 提出建议的过程中重新评估申请。参见为支持 2018 年 9 月 4 日向 BAMC 进行的口头介绍而提交的书面材料,第 1 页 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf)。《ICANN 章程》的适用版本指示 BAMC 只考虑受质疑的行动是否违反了既定 ICANN 政策或程序,而未授权 BAMC 对申请进行重新审核。参见《ICANN 章程》,2016 年 2 月 11 日,第 IV 条第 2.1、2.2 款。

71 参见请求 16-12,第 8 节,第7-10 页。

72 CPE 流程审核范畴 2 报告,第36-37 页 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf)。

73 同上

74 Merck & Co., Inc. CPE 报告,第 4 页。

75 同上

76 请求,第 8 节,第 9 页。

77 同上

78 参见请求 16-12,第 8 节,第 7-10 页。

79 参见《指导手册》第 4 单元,第 4.2.3 节。

80 2017 年简报摘要,第 3 页 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-summary-bgc-presentation-31mar17-en.pdf)。

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

82 CPE 报告,第 3-4 页。

83 同上,第 4-13 页。

84 同上,第 4-14 页。

85 CPE 报告,第 5 页;另请参见《指导手册》第 4 单元,第 4.2.3 节,第 4-14 页(“关于‘唯一性’评分为 1 分的条件,短语‘...除识别社群以外’意味着要求字符串确实识别社群,即‘联系’评分必须为 2 或 3 分,才能满足‘唯一性’评分为 1 分的条件。”)。

86 请求,第 8 节,第 11 页。

87 请求 16-12,第 8 节,第 6 页。

88 同上

89 参见 https://www.icann.org/resources/board-material/resolutions-2011-06-20-en#1。根据 2012 年 6 月有效的《章程》,重审请求应在发布与受质疑的董事会行动有关的信息后三十天内提交,或在请求者知晓或理应知晓受质疑的员工行动后三十天内提交。《ICANN 章程》,2012 年 3 月 16 日,第 IV 条第 2.5 款 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV)。

90《指导手册》第 6 单元,第 6 节,第 6-4 页。

91 在针对 .MERCK gTLD 提交竞争性申请的过程中,请求者和 Merck & Co., Inc. 针对彼此提出了异议,请求者还在提出与该异议有关的 IRP 诉讼时行使了这项权利。参见 https://www.icann.org/en/system/files/files/irp-merck-final-declaration-11dec15-en.pdf

92 范畴 2 报告,第 2 页 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf)。请求者认为,范畴 2 报告“对于 Merck KGaA 的重审请求没有意义”。(Bettinger 2018 年 4 月 12 日致 ICANN 信函,第 8 页。)但是,范畴 2 报告的结论与请求者的以下申诉直接相关:CPE 提供商就子标准 2-A“联系”确定的评分与 CPE 提供商对 .SPA、.RADIO、.ART 和 .ECO 的同一子标准确定的评分不一致。

93 Bettinger 2018 年 4 月 12 日致 ICANN 信函,第 6 页 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-supp-submission-12apr18-en.pdf)。另请参见为支持 2018 年 9 月 4 日向 BAMC 进行的口头介绍而提交的书面材料,第 7 页 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf)。

94 Bettinger 2018 年 4 月 12 日致 ICANN 信函,第 10 页。

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

96 例如,参见 DIDP 请求 20180115-1 及其相关响应 (https://www.icann.org/resources/pages/didp-20180115-1-ali-request-2018-02-15-en)(2018 年 7 月 18 日否决的重审请求 [https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.c]);DIDP 请求 20180110-1 及其相关响应 (https://www.icann.org/resources/pages/didp-20180110-1-ali-request-2018-02-12-en)(2018 年 7 月 18 日否决的重审请求 [https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.b])。

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