Skip to main content
Resources

批准的董事会决议 | 董事会工作坊公开会议,洛杉矶 | ICANN 董事会例行会议

本页面还提供其他语种:

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

  1. 认可议程:
    1. 批准会议记录
    2. 暂缓(域名)转入注册服务机构授权书的合规执行
    3. 《根区标签生成规则技术应用建议》
    4. 采纳 2021 财年 IANA 运营规划和预算
    5. 竞争、消费者信任和消费者选择 (CCT) 审核 — 六条已获批建议的实施规划
    6. 布鲁塞尔办事处分部经理和法律代表
  2. 主要议程:
    1. GAC 建议:《蒙特利尔公报》(2019 年 11 月)
    2. 将代表巴林的阿拉伯文域名 البحرين.(“albahrain”)授权给电信监管局 (TRA)
    3. 将代表老挝人民民主共和国的老挝语域名 .ລາວ(“Lao”)授权给老挝国家互联网中心 (LANIC)
    4. 考虑 BAMC 关于重审请求 19-4 的建议

  1. 认可议程:

    1. 批准会议记录

      第 2020.01.26.01 号决议:董事会批准 2019 年 11 月 3 日 ICANN 董事会例行会议、2019 年 11 月 21 日 ICANN 董事会特殊会议和 2019 年 12 月 12 日 ICANN 董事会特殊会议的会议记录。

    2. 暂缓(域名)转入注册服务机构授权书的合规执行

      鉴于转移政策要求注册服务机构域名转移“只有在(域名)转入注册服务机构收到转移联系人的转移确认之后才能开始转移”,并且这类授权“必须通过有效的标准化授权书 (FOA) 作出”。

      鉴于 2019 年 10 月 9 日,注册服务机构利益相关方团体 (RrSG) 致信 GNSO 理事会,报告称 RrSG 已确定实施(域名)转入注册服务机构 FOA 要求存在问题,并要求理事会请求 ICANN 董事会将此问题移交到即将进行的转移政策审核,同时指示 ICANN 合同合规部门在进行此类审核期间不要执行(域名)转入注册服务机构 FOA 要求。

      鉴于 2019 年 10 月 31 日,GNSO 理事会请求 ICANN 董事会指示 ICANN 组织暂缓(域名)转入注册服务机构 FOA 要求的合规执行,直到 GNSO 在计划的转移政策审核过程中解决此事项。

      兹此发布第 2020.01.26.02 号决议:董事会接受 GNSO 理事会的请求,并指示 ICANN 总裁兼首席执行官或其指定人员暂缓转移政策的(域名)转入注册服务机构 FOA 要求的合规执行,直到 GNSO 理事会在计划的转移政策审核过程中解决此事项。

      第 2020.01.26.02 号决议的理由

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

      董事会解决此问题是为了回应 GNSO 理事会的请求。2019 年 10 月 31 日,GNSO 理事会向 ICANN 董事会发送信函,请求董事会指示 ICANN 组织暂缓合同合规部门执行转移政策的(域名)转入注册服务机构 FOA 要求,直到在 GNSO 计划的转移政策审核过程中解决此事项。

      正在考虑的提案是什么?

      正在考虑的提案是 GNSO 理事会提出的请求,即 ICANN 董事会应指示 ICANN 组织暂缓合同合规部门执行转移政策中关于(域名)转入注册服务机构 FOA 的要求。

      转移政策要求注册服务机构域名转移“只有在(域名)转入注册服务机构收到转移联系人的转移确认之后才能开始转移。”这类授权“必须通过有效的标准化授权书 (FOA) 作出”。2018 年 5 月 25 日生效、在某些情况下取代这项(域名)转入注册服务机构 FOA 要求的临时规范规定:“在 ICANN 要求提供 RDAP 服务(或其他转移数据的安全方法)之前,如果(域名)转入注册服务机构无法访问某个应进行转移的域名当时的最新注册数据,转移政策中的相关要求将作废…[。]”临时规范附录 G 第 1.1 节指出,如果(域名)转入注册服务机构无法访问某个应进行转移的域名当时的最新注册数据,则“(域名)转入注册服务机构将不需要从转移联系人那里获取授权书。”

      但是,只有当公共 WHOIS/注册数据目录服务 (RDDS) 在提出转移请求时无法访问当时最新的注册数据,才适用临时规范附录 G 中的此替代条款。如果公共 WHOIS/RDDS 中显示了注册数据,则(域名)转入注册服务机构 FOA 要求继续适用。

      如下文详细介绍的,注册服务机构利益相关方团体 (RrSG) 已确定实施此要求存在问题。GNSO 理事会在向董事会提交请求时引述了这些问题。

      2019 年 5 月 20 日生效的 gTLD 临时注册数据政策(临时政策)要求继续实施与临时规范相一致的措施。此外,gTLD 注册数据临时规范快速政策制定流程第 1 阶段《最终报告》的建议 24 与临时规范相一致,并且未改变当前的合同义务。因此,即使注册数据政策生效,RrSG 确定的实施问题仍会继续存在。

      鉴于存在这些实施问题,GNSO 理事会请求 ICANN 董事会移交(域名)转入注册服务机构 FOA 问题以进行预期的转移政策审核,并指示 ICANN 组织暂缓(域名)转入注册服务机构 FOA 要求的合规执行,直到在转移政策审核过程中解决此问题。

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

      RrSG 在致 GNSO 理事会的 2019 年 10 月 9 日信函中就(域名)转入注册服务机构 FOA 要求提出了疑虑。在提出这些问题时,RrSG 表示实施转移政策时必须遵循通用数据保护条例 (GDPR)、加利福尼亚消费者隐私法案 (CCPA) 和其他适用的隐私法。

      RrSG 在其信函中指出,即使公共 RDDS 输出的注册人电子邮件字段中显示了数据,但由于电子邮件被有意混淆、编造,被 Web 格式的 URL 所取代,或使用假名的电子邮件地址,发送到该地址的电子邮件可能不会直接提交给注册人。他们认为,如果注册服务机构部署系统将(域名)转入注册服务机构 FOA 发送到公共 RDDS 中列出的任何地址,将无法保证注册人会收到该电子邮件。因此,注册服务机构声称,他们无法构建可靠的自动化流程来处理注册服务机构之间大量的转移活动。注册服务机构表示,这最终会违背转移政策的初衷,即:使注册人能够将域名转移到其他注册服务机构。另外,RrSG 称,许多注册服务机构认为,根据欧盟通用数据保护条例 (GDPR),(域名)转入注册服务机构不得处理此类信息,因为那要求注册服务机构向并非其客户的个人发送电子邮件。

      在 2018 年 5 月 1 日采纳临时规范之前,签约方机构 (CPH) Tech-Ops 委员会建议 ICANN 组织取消(域名)转入注册服务机构 FOA 要求,并在一封信函中称:“在 2018 年 5 月 25 日之后,(域名)转入注册服务机构将无法从公共 WHOIS 输出中提取注册人电子邮件或代理;(域名)转出注册服务机构或注册管理机构将无法提供一致的数据。”他们进一步指出,当前的转移流程(要求提供两份 FOA)是在注册服务机构之间一致地使用授权代码之前制定的。此外,委员会认为,(域名)转入注册服务机构 FOA 在域名转移期间提供的保护可以忽略不计,而且在出现转移纠纷时,注册服务机构很少依赖(域名)转入注册服务机构 FOA。

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

      RrSG 在 2019 年 10 月 9 日发送的信函中称,他们“注意到,在临时规范生效后,绝大多数 ICANN 认证注册服务机构都不再发送(域名)转入注册服务机构 FOA,并且似乎没有证据表明非授权转移自 2018 年 5 月以来有所增加。”另外,ICANN 合同合规部发现,有关非授权转移的投诉并未出现显著增加。ICANN 合同合规部收集的数据表明,在采纳临时规范前的 13 个月(2017 年 5 月 – 2018 年 5 月)中,处理了 143 例非授权转移;采纳临时规范后紧接着的 13 个月(2018 年 6 月 – 2019 年 6 月)中,处理了 138 例非授权转移。

      CPH Tech-Ops 委员会指出,转移 gTLD 期间,如果公共 RDDS 中未显示电子邮件地址,AuthInfo 代码足以确认注册人的转移意图。(域名)转出注册服务机构 FOA 也确认了这种意图。

      (域名)转入注册服务机构 FOA 要求仍然会给许多注册服务机构带来实施难度并造成合规问题。这段暂缓的合规期间将为 ICANN 社群留出时间,以通过转移政策审核考虑(域名)转入注册服务机构 FOA 要求。而且,额外留出的时间将允许受影响的签约方评估转移政策受到的任何潜在影响,并允许 ICANN 合同合规部履行职能,集中资源来处理更加紧迫或影响更大的请求。

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

      此项行动预计不会对 ICANN 资源、社群和/或公众产生任何财务影响。

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

      预计不会对 DNS 的安全、稳定或弹性造成任何影响。

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

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

      此项行动是否符合 ICANN 的使命?它与全球公共利益有什么关系?

      此项行动符合 ICANN 的使命和公共利益,因为它有助于确保一致和协调地实施 gTLD 政策。

    3. 《根区标签生成规则技术应用建议》

      鉴于 ICANN 董事会于 2013 年 11 月 4 日批准了涉及国际化域名应用标签的根区标签生成规则制定和维护规程,该规程已得到实施,以逐步制定根区标签生成规则 (RZ-LGR),确定有效的顶级域 (TLD) 及其变体标签。

      鉴于多个语言文字社群已完成其 RZ-LGR 提案,其中 16 种文字已整合到第三版 RZ-LGR 中,剩下的许多种文字正在拟定其最终 RZ-LGR 提案。

      鉴于 ICANN 董事会于 2019 年 3 月 14 日批准关于管理 IDN 变体字 TLD 的建议,该建议要求使用 RZ-LGR 来确定有效的 IDN TLD 及其变体标签,请求 ccNSO 和 GNSO 在制定各自的与 IDN 变体字 TLD 有关的政策时考虑这些建议,同时确保提供一致的解决方案。

      鉴于 ICANN 董事会进一步请求 ICANN 社群组建研究小组,调查采用 RZ-LGR 来确定有效的 IDN TLD 及其变体标签时存在的任何技术问题。

      鉴于 ICANN 社群组建的研究小组在采纳社群意见后最终拟定了 RZ-LGR 技术应用建议,并于 2019 年 10 月 7 日公布了这些建议。这些建议已通过 ICANN 组织的审核,并经过 ICANN 董事会考量。

      兹此发布第 2020.01.26.03 号决议:董事会请求 ccNSO 和 GNSO 理事会在制定各自的政策时考虑 RZ-LGR 技术应用建议,以便为当前的 TLD 以及将来的 TLD 申请定义和管理 IDN 变体字 TLD。

      第 2020.01.26.03 号决议的理由

      社群于 2012 年在问题整合报告 (IIR)1 中就 IDN 变体字 TLD 相关问题完成的初步工作确定,关于顶级标签之间变体关系的构成,并没有公认的定义。为解决此问题,ICANN 组织和社群制定了涉及国际化域名应用标签的根区标签生成规则制定和维护规程(LGR 规程)2。此规程可为不同文字定义标签生成规则,以确定有效的 TLD 标签及其变体标签。2013 年,ICANN 董事会对此规程表示支持,并请求 ICANN 组织和社群执行这份规程。根据 LGR 规程规定的流程,到目前为止,有多个生成专家组 (GP) 已完成其 RZ-LGR 提案,其中 16 种文字已整合到第三版 RZ-LGR (RZ-LGR-3) 中。许多其他语言文字社群也在拟定其最终 RZ-LGR 提案。此外,ICANN 董事会批准了与管理 IDN 变体字 TLD 有关的建议3,这些建议要求使用 RZ-LGR 来确定有效的 IDN TLD 及其变体标签,并请求 ccNSO 和 GNSO 在其政策制定流程中考虑这些建议。

      随着 RZ-LGR 的制定并且预计它将主要用于确定有效的 TLD 及其变体标签,ICANN 董事会请求 ICANN 社群(包括支持组织 [SO]、咨询委员会 [AC]互联网架构委员会 [IAB])从技术的角度,对跨所有 IDN TLD(包括 IDN gTLD 和 IDN ccTLD)一致地应用 RZ-LGR 时存在的问题展开调查。因此,为处理 ICANN 董事会提出的请求,成立了一个由 SO、AC、IAB 提名人员和来自 ICANN 社群的其他志愿者组成的 RZ-LGR 研究小组 (SG)。RZ-LGR SG 成立后,首先确定了其工作范围,并通过在 2018 年 8 月举行的首轮公共评议中征询社群的反馈意见最终确定了该范围。SG 根据这一范围审议了相关技术细节并拟定了一组建议。这些建议由 SG 于 2019 年 5 月在第二轮公共评议期间发布。根据社群的意见,SG 最终确定并于 2019 年 10 月 7 日公布这些建议,以供 ICANN 董事会进一步考量。

      由于要根据 LGR 规程维护 RZ-LGR,并根据 RZ-LGR 部署和维护 LGR 工具来处理 TLD 标签,这些建议将产生财务影响。维护 RZ-LGR 所产生的持续财务影响,预计将远小于现在为制定该规程而提供的财务支持。此外,ICANN 组织已开发并部署 LGR 工具来支持基于文字的 GP 拟定其 RZ-LGR 提案,将来可以利用这些提案来处理 TLD 标签。实际财务影响还取决于最终提出的建议,这些建议由 ccNSO 和 GNSO 理事会通过其各自的与 IDN TLD 及其变体标签有关的政策流程编制,并由 ICANN 董事会予以采纳。

      这些建议符合 ICANN 的使命并有助于确保唯一标识符系统以多种方式保持安全稳定运营,因为它们:支持跨 gTLD 和 ccTLD 并针对现有 TLD 和将来的 TLD 申请对 IDN 变体字 TLD 进行统一定义;支持采用社群主导的机制以根据 LGR 规程来维护 RZ-LGR,以确保其稳定性;同时突出并处理了通过 RZ-LGR 允许的操作与在根区中授权的操作之间的差异。在实现这一目标的同时也尊重了社群的政策制定角色。支持应用 RZ-LGR 以一致地确定并在可能情况下授权 IDN 变体字 TLD 的工作,还通过增强以不同文字访问互联网域名系统 (DNS) 来促进公共利益。

    4. 采纳 2021 财年 IANA 运营规划和预算

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

      鉴于已审核并回复通过公众意见征询流程收到的意见,并将其提供给董事会财务委员会 (BFC) 进行审核与评议。

      鉴于已考虑所有公众意见,并将适当、可行的意见纳入 2021 财年最终 IANA OP&B。根据《章程》,董事会将采纳 IANA OP&B 并在 ICANN 网站上公布。

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

      兹此发布第 2020.01.26.04 号决议:董事会通过 2021 财年运营规划和预算

      第 2020.01.26.04 号决议的理由

      根据《ICANN 章程》第 22.4 款,董事会负责通过 IANA 年度预算并将其发布到 ICANN 网站上。2021 财年 PTI 运营规划和预算 (OP&B) 草案和 2021 财年 IANA OP&B 草案已于 2019 年 10 月 14 日发布以征询公众意见。PTI 董事会于 2020 年 1 月 9 日批准了 2021 财年 PTI OP&B,PTI 预算为 2021 财年 IANA OP&B 提供了参考信息。

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

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

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

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

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

      这属于组织管理职能,已征询公众意见(如上所述)。

    5. 竞争、消费者信任和消费者选择 (CCT) 审核 — 六条已获批建议的实施规划

      鉴于《义务确认书》规定 ICANN 有责任“组织一次审核,评估 gTLD 的引入或扩张在何种程度上促进了竞争、消费者信任和消费者选择,以及确定 (a) 申请和评估流程的有效性和 (b) 为解决引入或扩张期间所出现问题而落实的保护措施的有效性”。一个由社群领导的审核小组 — 竞争、消费者信任和消费者选择审核小组 (CCT-RT) — 于 2015 年 12 月 23 日宣布成立,旨在完成这项任务。

      鉴于 2018 年 9 月 8 日,CCT-RT 向 ICANN 董事会提交了包含 35 项获得一致支持的建议的最终报告(下称“最终报告”)供其考量。

      鉴于 ICANN 董事会对最终报告中题为“最终 CCT 建议:董事会行动(2019 年 3 月 1 日)”的平衡记分卡(下称“平衡记分卡”)中列明的所有 35 条建议采取了行动。

      鉴于董事会基于成本和实施考量决定采纳平衡记分卡中列明的 CCT 建议 1、17、21、22、30、31,并指示 ICANN 总裁兼首席执行官或其指定人员编制一份计划提交给董事会,以实施已经获批的建议,目的是在董事会采取此行动后的六个月内完成该计划并提供给社群供其考量。

      鉴于 2019 年 9 月 11 日提交了实施规划以征询公众意见。此外,还就上述提案征询了社群反馈,以酌情在 ICANN 的运营规划和预算流程中落实 CCT 建议,适当排定所有 ICANN 工作的优先次序。在征询反馈的过程中总共收到了五条意见;ICANN 组织编写的摘要中提供了分析过程和 ICANN 组织对所收到意见的回复。

      兹此发布第 2020.01.26.05 号决议:董事会指示 ICANN 总裁兼首席执行官或其指定人员根据实施规划的安排开始落实接受的 CCT-RT 建议。由于所需成本和资源不会显著增加,应尽早开始实施工作。实施规划中提到的任何需要大量资源和预算的 CCT 建议应纳入到运营规划和预算流程中,以便社群根据情况做出适当考量并排定计划工作的优先次序。

      第 2020.01.26.05 号决议的理由

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

      如 ICANN 章程第 1 条所详述,审核是重要的问责措施,对于维持健康的多利益相关方模型和帮助 ICANN 履行其使命至关重要。审核也有助于确保 ICANN 服务于公共利益。根据《义务确认书》(AoC) 启动的首次竞争、消费者信任和消费者选择审核 (CCT) 是 ICANN 持续审核和评估相关关键领域承诺的重要组成部分。

      竞争、消费者信任和消费者选择审核小组 (CCT-RT) 于 2018 年 9 月 8 日向 ICANN 董事会提交了其最终报告建议

      2019 年 3 月 1 日,ICANN 董事会对 CCT-RT 提出的最终建议采取行动。依照《ICANN 章程》,ICANN 董事会仔细考虑了如何以最佳方式处理每条建议,并决定采取三类行动:采纳、待定以及移交到不同的社群团体,董事会决议随附的详细平衡记分卡记录了这些类别的行动。

      目前,董事会正采取行动,为落实实施规划中列明的已采纳建议提供指导。

      正在考虑的提案是什么?

      ICANN 组织制定了实施规划来落实董事会第 2019.03.01.03 号决议,以便:1) 基于成本和实施考量采纳 CCT 建议 1、17、21、22、30、31;并且 2) 指示 ICANN“编制一份计划提交给董事会,以实施已经获批的建议”。

      实施规划列出了实施已采纳的建议所采用的方法。其中包含了各种信息,如活动说明、估计的持续时间、资源要求(包括融资来源)、依赖条件,以及其他可能适用的要素。

      除了详述实施里程碑和步骤以外,实施规划还尽可能详细地说明了完成实施工作预计所需的成本和资源。它解释了如何为特定建议分配资源以支持 ICANN 履行其使命,了解资源平衡和所需的优先排序,以便为确定的工作筹措资金来落实 CCT-RT 建议。

      实施规划由 ICANN 组织主题问题专家根据六条已采纳建议的主题制定。

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

      实施规划已于 2019 年 9 月 11 日发布以征询公众意见。此外,还就上述提案征询了社群反馈,以在运营规划和预算流程中落实 CCT 建议,在更广泛的背景下适当排定所有 ICANN 工作的优先次序。反馈意见征询于 10 月 31 日结束,总共收到了五条意见。公众意见摘要报告的“分析”部分根据情况处理了这些意见。

      在发布实施规划之前,CCT-RT 实施指导人4受邀加入专门负责 CCT 工作的董事会决策委员会小组,以大致了解为开展 3 月 1 日董事会有关 CCT 最终建议的行动而拟定的路线和计划。

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

      实施规划中所阐述的,在某些情况下,落实这些建议所需的资源可能会超出当前预算分配的限额。因此,董事会决议要求,将实施规划中提到的需要大量资源和预算的那些建议纳入运营规划和预算周期。

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

      采纳实施规划将有助于 ICANN 组织尽快开始落实社群领导的审核小组提出的某些建议。如实施规划中所述,预计落实某些建议将需要社群参与某些磋商。这可能会对社群的工作量和资源造成潜在影响。

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

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

      此项行动是否符合 ICANN 的使命?它与全球公共利益有什么关系?

      此项行动在 ICANN 的使命和职责范围内。它符合公共利益,因为它履行了 2009 年在《义务确认书》中做出、现在体现在《ICANN 章程》中的关键承诺。审核是 ICANN 履行其承诺的过程中的一个重要基本组成部分。从本质上说,此次审核的范围与 ICANN 在域名注册方面引入和推动竞争的核心价值理念密切相关。

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

      在董事会考量之前已收到公众意见。

    6. 布鲁塞尔办事处分部经理和法律代表

      鉴于将主要办公场所设在 12025 E. Waterfront Drive, Suite 300, Los Angeles, California USA 90094,且根据加利福尼亚州和美国法律正式成立并存在的非营利性公益型企业互联网名称与数字地址分配机构(简称“ICANN”),已在比利时设立一个非营利性国外实体分部办事处,目前的地址位于布鲁塞尔 6 Rond Point Schuman, B-1040,机构名称为互联网名称与数字地址分配机构。

      鉴于根据 ICANN 董事会第 2017.06.24.13 号决议,让-雅克·萨赫尔 (Jean-Jacques Sahel) 被任命为比利时分部经理和法律代表,担任此职务直到董事会发布决议撤销其任命。

      鉴于让-雅克·萨赫尔作为比利时分部经理和法律代表的职务将于 2019 年 10 月到期,之后他将从 ICANN 辞职。

      鉴于自 2020 年 1 月 26 日起,克里斯托弗·蒙蒂尼 (Christopher Mondini) [可识别个人身份的联系信息]将继任 ICANN 比利时布鲁塞尔办事处分部经理和法律代表职务。

      兹此发布第 2020.01.26.06 号决议:撤销让-雅克·萨赫尔作为 ICANN 比利时布鲁塞尔分部办事处分部经理和法律代表的权力,撤销即刻生效。

      第 2020.01.26.07 号决议:自 2020 年 1 月 26 日起,克里斯托弗·蒙蒂尼将担任 ICANN 比利时布鲁塞尔分部办事处新任分部经理和法律代表。

      第 2020.01.26.08 号决议:授予克里斯托弗·蒙蒂尼全权负责 ICANN 比利时布鲁塞尔分部办事处的日常管理,包括但不限于关于该分部运营的以下具体权力:

      1. 代表该分部处理与所有公共权威机构的关系,无论是政府、区域、省级、市级或其他机构还是企业法院 (Enterprise Courts)、企业十字路口银行 (Crossroads Bank for Enterprises)、企业柜台 (Corporate Counters)、税务当局(包括增值税管理部门)、邮政支票服务、关税、邮政、电话和电报服务,以及所有其他公共服务和机构。

      2. 签署日常信函,接收通过邮政、海关、铁路、航空以及其他运输公司和服务寄送到该分部的挂号信或包裹。

      3. 购买、签署、转让或取消该分部的所有保险单和所有供水、燃气、电力、电话等公用事业合同,并支付相关的费用清单、账单和其他与此相关的应付费用。

      4. 签署并接受购买或出售分部运营所必需的办公设备和其他投资产品、服务和用品的所有报价单、合同和订单,分部的此项支出不得超出 500 欧元。

      5. 在获得 ICANN 总裁兼首席执行官或 ICANN 董事会的同意后,对房地产、设备或其他固定资产进行租赁(包括长期租赁),并为此此签订租赁协议。

      6. 要求、收取和接收任何类型的金钱、文件或财产,并签署收据。

      7. 让分部与任何专业或商业组织建立附属关系。

      8. 在法庭审理或仲裁程序中代表分部作为原告或被告,针对上述程序采取所有必要措施,获得所有判决并使判决得到执行。

      9. 起草和签署所有必要文件,以便能够行使上述权力。

      10. 采取所有必要措施以实施董事会决议和建议。

      11. 在获得 ICANN 总裁兼首席执行官或 ICANN 董事会批准的前提下,将分部迁址至比利时境内的其他地点。

      第 2020.01.26.06 – 2020.01.26.08 号决议的理由

      ICANN 致力于在全球各个时区继续拓展其全球足迹。为此,ICANN 董事会通过了在比利时设立分部办事处的决议,并于 2017 年任命让-雅克·萨赫尔作为分部经理和法律代表,授予其相关权力以履行这些职责。萨赫尔先生将于 2019 年 10 月从 ICANN 辞职。这要求董事会任命一位新的分部经理和法律代表。这项决议任命蒙蒂尼先生在前任分部经理和法律代表辞职之后担任分部经理和法律代表,授予其管理分部的特定权力,继续为 ICANN 开展有效的分部办事处管理工作。

      ICANN 在全球范围内的承诺符合公共利益并与 ICANN 的使命一致,因为它有助于支持 ICANN 的全球利益相关方工作重心。

      只有任命新分部经理的相关费用会对 ICANN 产生财务影响,但此等影响已经在 2020 财年预算中纳入考虑。

      此决定预计不会对域名系统的安全、稳定与弹性产生任何影响。

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

  2. 主要议程:

    1. GAC 建议:《蒙特利尔公报》(2019 年 11 月)

      鉴于政府咨询委员会 (GAC) 在 ICANN 第 66 届加拿大蒙特利尔会议期间召开会议,并于 2019 年 11 月 6 日发表公报(下称“蒙特利尔公报”),其中包含四条共识性建议和三条针对先前建议的跟进建议。共识性建议涉及 CCT 审核和新 gTLD 的后续轮次,以及域名注册目录服务和数据保护。针对先前建议的跟进建议涉及保护红十字会和红新月会名称和标识符、IGO 保护,以及域名注册目录服务和数据保护。

      鉴于在 2019 年 12 月 16 日信函中,ICANN 总裁兼首席执行官提供了与 CCT 审核实施工作有关的信息,并就 GAC 关于该主题的建议向 GAC 主席提出需澄清的问题。

      鉴于在 2019 年 12 月 17 日的电话会议中,ICANN 董事会与 GAC 讨论了《蒙特利尔公报》和 ICANN 董事会就 GAC 建议提出的一些需澄清问题。

      鉴于在 2019 年 12 月 19 日信函中,GNSO 理事会向董事会就《蒙特利尔公报》中包含的针对先前建议的跟进建议提供了它的反馈。

      鉴于在 2020 年 1 月 6 日信函中,ICANN 组织应 GAC 在《蒙特利尔公报》中提出的请求提供了与 EPDP 第 1 阶段实施时间安排有关的情况更新。

      鉴于在 2020 年 1 月 22 日信函中,GAC 就其在《蒙特利尔公报》中提出的建议提供了更多澄清说明。

      鉴于董事会在考虑了其与 GAC 之间就该主题以前进行的沟通以及 GNSO 理事会提供的信息之后,制定了一张平衡记分卡,用于回应 GAC 在《蒙特利尔公报》中提出的建议。

      兹此发布第 2020.01.26.09 号决议:董事会采纳名为“GAC 建议 — 蒙特利尔公报:行动与更新(2020 年 1 月 26 日)”的平衡记分卡,以回应《蒙特利尔公报》GAC 建议中的事项。

      第 2020.01.26.09 号决议的理由

      根据《ICANN 章程》第 12 条第 12.2(a)(ix) 款,GAC 可以“直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议”。在其《蒙特利尔公报》(2019 年 11 月 6 日)中,GAC 就 CCT 审核和新 gTLD 的后续轮次,以及域名注册目录服务和数据保护向董事会提出共识性建议。此外,GAC 还就保护红十字会和红新月会名称和标识符、IGO 保护,以及域名注册目录服务和数据保护提出了针对先前建议的跟进建议。《ICANN 章程》要求董事会在制定和采纳政策时考虑 GAC 就公共政策问题提供的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。对于 GAC 完全达成共识(按照《章程》规定)的任何 GAC 建议,只有不少于 60% 的董事会成员投反对票后才可予以否决。然后,GAC 和董事会必须尝试真诚、及时、高效地寻找双方都可以接受的解决方案。

      董事会今天就《蒙特利尔公报》中的所有事项采取了行动。

      2020 年 1 月 26 日的平衡记分卡中介绍了董事会的行动。

      在采纳对《蒙特利尔公报》中 GAC 建议的回应时,董事会审核了诸多材料,包括但不限于以下材料和文件:

      采纳平衡记分卡中提供的 GAC 建议有助于解决 GAC 关于 gTLD 和其他事项的建议,将对社群产生积极影响。根据 GAC 建议采取行动符合 ICANN 的使命和 GAC 在 ICANN 的多利益相关方模型中的角色,并且支持了公共利益。通过此项决议不会产生任何可预见的财务影响。批准此项决议不会产生任何与 DNS 相关的安全、稳定或弹性问题。这属于组织管理职能,无需征询公众意见。

    2. 将代表巴林的阿拉伯文域名 البحرين.(“albahrain”)授权给电信监管局 (TRA)

      兹此发布第 2020.01.26.10 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,IANA 审核并评估了将顶级域 البحرين. 授权给电信监管局的申请。相关文件证明,在评估该申请时遵循了适当的程序。

      第 2020.01.26.10 号决议的理由

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

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

      正在考虑的提案是什么?

      正在考虑的提案是批准一项申请,该申请希望创建阿拉伯文国家和地区顶级域 البحرين. 并将经理人的角色分配给电信监管局。

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

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

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

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

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

      董事会审核了以下评估:

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

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

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

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

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

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

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

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

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

    3. 将代表老挝人民民主共和国的老挝语域名 .ລາວ(“Lao”)授权给老挝国家互联网中心 (LANIC)

      发布第 2020.01.26.11 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,IANA 审核并评估了将顶级域 .ລາວ 授权给老挝国家互联网中心的申请。相关文件证明,在评估该申请时遵循了适当的程序。

      第 2020.01.26.11 号决议的理由

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

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

      正在考虑的提案是什么?

      正在考虑的提案是批准一项申请,该申请希望创建老挝语国家和地区顶级域 .ລາວ 并将经理人的角色分配给老挝国家互联网中心。

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

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

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

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

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

      董事会审核了以下评估:

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

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

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

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

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

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

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

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

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

    4. 考虑 BAMC 关于重审请求 19-4 的建议

      鉴于 Merck KGaA 和 Merck Registry Holdings, Inc.(请求人)提交了重审请求 19-4,寻求重审 ICANN 组织对其共同请求 — 即要求第二次推迟 .MERCK 通用顶级域 (gTLD) 的字符串争用拍卖(二次请求)的否决一案。

      鉴于请求人声称 ICANN 员工在否决二次请求时未考虑实质性信息,并违背了支持自愿解决字符串争用并允许酌情取消最终期限的既定 ICANN 政策。

      鉴于请求人进一步指出,否决二次请求违背了 ICANN 在其《章程》中做出的“在进行决策时,秉持中立、客观、正直、公正的原则运用成文政策”的承诺。

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

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

      鉴于 BAMC 仔细考虑了请求 19-4 的依据和所有相关材料,并建议否决请求 19-4,原因如下:在否决请求人的二次请求时,ICANN 员工并非没有考虑实质性信息,也没有违背 ICANN 的承诺、核心价值或既定 ICANN 政策。

      鉴于 BAMC 建议董事会要求 ICANN 组织向请求人寻求情况更新,如果请求人做出联合声明,表明他们已在提交请求 19-4 后取得进展,并且他们已非常接近于达成私下解决方案,则可考虑酌情提供某种形式的缓解措施,为请求人留出时间来最终确定私下解决方案。

      鉴于请求人依照《ICANN 章程》第 4 条第 4.2(q) 款提交了针对 BAMC 建议反驳意见

      鉴于反驳意见提供了请求人就字符串争用问题达成私下解决方案所取得进展的情况更新,声明请求人不可能在下个月解决他们有关 .MERCK 的争议,并请求将拍卖推迟到 2020 年 8 月底。

      兹此发布第 2020.01.26.12 号决议:董事会采纳 BAMC 建议并因此否决重审请求 19-4。

      第 2020.01.26.13 号决议:董事会指示总裁兼首席执行官或其指定人员就解决进度向请求人寻求其他情况更新。如果请求人做出联合声明称,他们已在提交请求 19-4 后取得进展,并且 ICANN 组织对于请求人已非常接近于达成私下解决方案感到满意,则董事会要求总裁兼首席执行官或其指定人员考虑酌情向请求人提供某种形式的缓解措施,为他们留出较短的一段时间来最终确定私下解决方案。

      第 2020.01.26.14 号决议:如果请求人未就他们的解决进度提供其他情况更新和/或如果 ICANN 组织对于请求人已非常接近于达成私下解决方案感到不满,则董事会将指示总裁兼首席执行官或其指定人员继续处理 .MERCK 申请,包括在 ICANN 组织认为适当的情况下安排拍卖。

      第 2020.01.26.12 – 2020.01.26.14 号决议的理由

      1. 简要概述和建议

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

        2019 年 12 月 19 日,BAMC 评估了请求 19-4 和所有相关材料,并建议董事会否决请求 19-4,原因如下:在否决请求人的二次请求时,ICANN 员工并非没有考虑实质性信息,也没有违背 ICANN 的承诺、核心价值或既定 ICANN 政策。

        2020 年 1 月 3 日,请求人依照《ICANN 章程》第 4 条第 4.2(q) 款提交了针对 BAMC 建议反驳意见(下称“反驳意见”)。请求人声称:(1) BAMC 曲解了请求人与“Merck”一词有关的商标权争议历史;(2) 《申请人指导手册》中禁止多次续约的规则不适用于请求人;(3) BAMC 以请求人未提交证据表明 ICANN 员工未能考虑实质性信息为由,对请求人做出了不当处罚;(4) 通过否决二次请求,ICANN 员工对请求人有歧视行为;并且 (5) 虽然请求人最初预计他们能够在 2020 年初解决字符串争用,但目前,请求人要求 ICANN 员工将拍卖推迟到 2020 年 8 月底,以便为请求人留出足够的时间,私下解决字符串争用问题。

        董事会仔细考虑了 BAMC 的建议及请求 19-4 的所有相关材料,并决定否决请求 19-4。尽管反驳意见指出,即使可以达成私下解决方案,也要等到 2020 年 8 月前,但依照 BAMC 建议,董事会仍要求 ICANN 组织就解决进度向请求人寻求其他情况更新。如果请求人做出联合声明称,他们已在提交请求 19-4 后取得进展,并且 ICANN 组织对于请求人比反驳意见陈述的情况更接近于达成私下解决方案感到满意,那么,董事会将要求 ICANN 组织考虑酌情向请求人提供某种形式的缓解措施,为他们留出有限的时间来最终确定解决方案。

      2. 问题

        问题如下:

        • 否决请求人就第二次推迟 .MERCK 字符争用集拍卖而提出的共同请求时,ICANN 员工是否未能考虑实质性信息。

        • 否决请求人就第二次推迟 .MERCK 字符争用集拍卖而提出的共同请求时,ICANN 员工是否违背了支持自愿解决字符串争用并允许酌情取消最终期限的既定 ICANN 政策。

        • 否决请求人就第二次推迟 .MERCK 字符争用集拍卖而提出的共同请求时,ICANN 员工是否违背了 ICANN“在进行决策时,秉持一致、中立、客观、公正的原则运用成文政策”的承诺。

      3. 分析和理由

        1. 在否决二次请求时,ICANN 员工并非没有考虑实质性信息

          ICANN 员工在否决二次请求时考虑了所有实质性信息。请求人辩称,ICANN 员工忽视了他们之间就“Merck”商标跨辖区进行诉讼的历史,事实上,请求人预计将在“今后几个月”收到几个未决案例的判决,同时,请求人“有望”能够“很快”通过自愿协议解决其对 .MERCK 的争用问题。5请求人表示,这些事实对于他们的二次请求至关重要。6BAMC 最终认定:(1) 请求人未提供任何证据来支持他们的以下论断:ICANN 员工未能考虑请求人的争议历史;(2) ICANN 员工清楚了解请求人漫长的争议历史;(3) ICANN 员工知道请求人正努力达成私下解决方案;并且 (4) 在任何情况下,有关请求人争议或其尝试达成私下解决方案的信息对 ICANN 员工就二次请求做出决定并不重要。7

          在其反驳意见中,请求人声称他们不需要提供证据来支持其关于 ICANN 员工未能考虑实质性信息的论断,而且此类消极行为无法证实。8董事会承认,在对二次请求做出决定时,ICANN 员工未明确引用请求人的“具有法律复杂性和政治敏感性的背景信息”9;但是,有记录表明,情况与请求人的论断恰恰相反,ICANN 员工清楚了解该背景信息。请求人必须反驳这一证据,但却无力反驳。因此,BAMC 最终认定并经董事会同意,ICANN 员工清楚了解请求人漫长且充满争议的历史。10

          此外,请求人也质疑 ICANN 员工在否决二次请求时所建议的:两个星期的时间可能已足够“私下争取并完全解决该字符争用集问题”。请求人声称“ICANN 员工并不全面了解”请求人在做出不懈努力来自愿解决争用问题的情况;否则(据请求人称),ICANN 员工就应意识到,鉴于复杂敏感的法律背景,两周时间并不足以让各方解决他们的争议。11但是,ICANN 员工在否决二次请求时仅仅表达了否决本身并不要求各方停止尝试私下解决字符串争用问题。该表述仅仅是为了明确在退出字符串争用的最终期限之前,各方可以继续进行协商。ICANN 员工否决二次请求并不表明 ICANN 员工不重视请求人争议的复杂性。董事会赞同 BAMC 的结论,即没有证据表明 ICANN 员工未能考虑这一信息。

          BAMC 认定,在任何情况下,与请求人争议历史及解决尝试有关的信息都不是实质性信息,与 ICANN 员工就二次请求做出的决定无关。12董事会赞同此结论。ICANN 员工否决二次请求的做法符合 ICANN 的以下规则:反对批准一个以上的、推迟任何字符争用集拍卖的请求,不论该请求出于何种原因提出。13

        2. ICANN 员工未违反支持自愿解决争用的 ICANN 政策。

          请求人声称 ICANN 员工否决二次请求违反了 ICANN 组织支持自愿解决字符争用集问题,并且仅将字符争用集拍卖作为最终解决机制的政策。14BAMC 最终认定并且董事会同意,否决二次请求符合并且未违反支持自愿解决字符串争用及仅将拍卖作为最终手段的 ICANN 政策。15

          《申请人指导手册》规定,推迟是“一种一次性选项;ICANN 将不会为每组争用申请批准多个此类请求”,在其反驳意见中,请求人对 BAMC 依赖这项规定做出决定提出质疑。16请求人声称,这项规定并不适用于他们,因为它位于《申请人指导手册》中论述社群优先评估程序的部分,对“发现有多个基于社群的申请符合标准”即符合社群优先标准的情况做出规定,而任何一个基于社群的 .MERCK 申请都不符合社群优先标准。17

          但是,尽管《申请人指导手册》对于只推迟一次规则的讨论位于“社群优先评估”部分,但《申请人指导手册》明确规定,就推迟拍卖而提出的共同请求会且只会批准一次。此外,值得注意的是,如 BAMC 指出并经请求人确认,《申请人指导手册》不是唯一提及该只推迟一次规则的文件。ICANN 的《拍卖日期提前/推迟申请表》(推迟申请表)解释称:“ICANN 可以允许为每个字符争用集提出一次推迟请求”。18BAMC 指出,最新版本的《新 gTLD 拍卖规定》提及了推迟申请表。19推迟申请表“规定收到了《拍卖意向》通知的申请人能够请求提前或推迟他们安排的拍卖日期”,前提是所有字符争用集成员都同意推迟(或提前)拍卖日期。20该表可以作为任何字符争用集中任何一组申请人的推迟请求表(只要字符争用集的所有成员都同意进行推迟)。推迟申请表不会将只推迟一次规则限定于任何特定类型的字符争用集 — 相反,它适用于所有字符争用集。21

          董事会认定,推迟申请表证明 ICANN 组织做出了对共同提出的推迟拍卖请求只批准一次的规定;《申请人指导手册》和拍卖规定中对推迟拍卖的论述,无法证明其有意将该规定的适用范围限定为某些类型的字符争用集,或者对于某些类型的字符争用集允许多次推迟拍卖。

          此外,请求人还在其反驳意见中表示,自 2019 年 5 月 2 日首次安排字符争用集拍卖之后的五个多月(现在超过八个月)里,他们一直在本着良好意愿寻求解决 .MERCK 字符争用集,但尽管如此,“实际情况要复杂得多”— 这很可能意味着,五个月的时间并不足够。22但是,应该指出的是,请求人实际有超过五个月的时间来解决他们的争议。请求人之间一直在着手解决争议达数十年之久。请求人知道,在他们于 2012 年提交竞争性 .MERCK 申请之后,或者至少在 2013 年 3 月 Merck KGaA 针对 Merck Registry Holdings, Inc. 与使用“Merck”名称有关的申请提出合法权利异议之后,如果他们无法达成私下解决方案,他们的申请注定会进行拍卖。23因此,请求人的这一论据无法支持重审。

          BAMC 最终认定,基于上述以及那些在 BAMC 建议中陈述的原因,董事会同意否决二次请求,更广泛地讲,ICANN 反对第二次推迟字符争用集拍卖的规定符合并且不违反支持自愿解决字符串争用及仅将拍卖作为最终手段的 ICANN 政策。此外,应指出的是,反对第二次推迟拍卖的规定并不会阻止解决争议,而只会防止各方通过提供拍卖最终期限无限期拖延 gTLD 争议。如果在一段合理的时间后未能解决争议,采用拍卖流程来提供保障既符合 ICANN 的“赞成和解”政策,也与其将拍卖作为最终机制来解决字符串争用的做法相一致。

        3. ICANN 员工未违背 ICANN 做出的中立、客观地运用政策的承诺。

          请求人声称,ICANN 员工否决二次请求违背了 ICANN 做出的“在进行决策时,秉持中立、客观、正直、公正的原则运用成文政策”的承诺。BAMC 最终认定并且董事会同意,ICANN 做出的中立运用政策的承诺或任何其他承诺不排除应用反对第二次推迟或要求在所有情况下酌情进行处理的 ICANN 规定。

          请求人在其反驳意见中指出,“鉴于这里情况的唯一性”,ICANN 员工在考虑二次请求时需要应用“灵活性和判断力”,即使 ICANN 组织在其他情况下禁止第二次推迟。24请求人称,这里提到的“唯一...情况”是指两名请求人保持“完全一致”,也就是他们“在推迟拍卖上达成完全一致”。25但是,那些情况并不唯一;申请人之间取得一致是请求推迟任何拍卖的先决条件。26董事会最终认定,这一论断无法支持重审。

          请求人不赞同 BAMC 的以下结论:通过确定将否决所有此类要求第二次推迟的请求,应用一次推迟规定“将同等地对待每一个请求”。27请求人认为,ICANN 员工否决二次请求将造成“歧视[请求人]”的后果。28请求人指出,ICANN 承诺“在进行决策时,秉持中立、客观、正直、公正的原则运用成文政策”29,“特别是避免‘对任何一方’予以歧视对待”。30但是,请求人未证实 ICANN 员工对任何一方进行了差别对待,因为他们既未确定 ICANN 员工以不同方式对待了任何一方,也未确定任何 ICANN 表示其政策允许多次推迟共同提出的拍卖请求的情况。董事会赞同 BAMC 的结论,即只推迟一次规则实际上允许 ICANN 员工同等地处理所有第二次推迟请求。因此,这一论据无法支持重审。

        4. 申请人不赞同禁止第二次推迟拍卖的规则并不构成重审依据。

          请求人完全不赞同 ICANN 组织在所有情况下否决第二次推迟的规定。31BAMC 最终认定,请求人的任何论据均不表明该规定违背了 ICANN 的使命、承诺、核心价值和/或既定 ICANN 政策,也没有为对否决二次请求进行重审提供依据。32

          请求人在反驳意见中澄清,他们不是对反对第二次推迟的规则本身提出质疑,相反,他们质疑的是“ICANN 员工否决第二次推迟拍卖的动机”。33基于在 BAMC 的建议中说明的原因,董事会得出结论,ICANN 员工否决二次请求的动机符合 ICANN 组织的只推迟一次规则。董事会认定,请求人关于 ICANN 员工动机的论据无法支持重审。

        5. 请求人关于解决争用讨论的情况更新。

          请求人在反驳意见中提供了情况更新,对他们认为与 .MERCK 谈判有关的未决诉讼的状态做出说明。请求人最初声称,他们“非常接近于达成解决方案”来解决争议,但据他们最新预计,结束在澳大利亚、中国、印度、瑞士、美国和英国的未决诉讼的日期约为 2020 年 6 月;他们同时称,“一旦我们做出上述决定并举行听证会,将更有利于我们寻求最终解决争用问题”。请求人当前请求在 2020 年 8 月底之前尝试解决字符串争用。34

          董事会认为,指示 ICANN 组织在不久的将来获取其他情况更新不可能得到新的或不同的信息。但是,董事会确认,请求人要求“就预计将于 2020 年 1 月完成的法院判决及他们在解决争用方面取得的进展向董事会提供更详细的情况更新”。35因此,董事会已指示总裁兼首席执行官或其指定人员就以下事项向请求人寻求情况更新:(i) 请求人是否收到任何请求人预计将在 2020 年 1 月完成的法院判决;以及 (ii) 请求人在解决争用方面取得了哪些进展(如果有的话)。如果请求人做出联合声明称,他们已在提交请求 19-4 后取得进展,并且 ICANN 组织对于请求人已非常接近于达成私下解决方案感到满意,那么,董事会将要求 ICANN 组织考虑酌情向请求人提供某种形式的缓解措施,为他们留出有限的时间来最终确定解决方案。如果请求人未就他们的解决进度提供其他情况更新和/或如果 ICANN 组织对于请求人已非常接近于达成私下解决方案感到不满,董事会将指示总裁兼首席执行官或其指定人员继续处理 .MERCK 申请,包括在 ICANN 组织认为适当的情况下安排拍卖。

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

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


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

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

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

4 CCT-RT 实施指导人为前任 CCT-RT 成员,他们自愿根据需要就建议的意图、理由、得出结论的事实依据、时间表和实施措施提供澄清说明。详情请查阅:https://community.icann.org/display/CCT/Implementation+Shepherds

5 请求 19-4,第 8 节,第7-8 页。

6 参见内容同上。

7 BAMC 建议,第9-10 页。

8 反驳意见,第3-4 页。

9 请求 19-4,第 8 节,第 7 页。

10 BAMC 建议,请参考:Pgs.4 n.28, 9.

11 反驳意见,第 4 页。此外,请求人还指出,BAMC 在其建议中声明,请求人“各自拥有与‘Merck’一词有关的商标权,数十年来,这一直并将继续是在多个辖区提起的诉讼的主题”;这一声明表明 ICANN 员工在评估二次请求时未考虑请求人的历史,因为“所有当前的诉讼案”是在请求人于 2012 年申请 .MERCK gTLD 之后发起的。反驳意见,第 3 页。请求人的法律诉讼是始于七年前还是几十年前并不重要,BAMC 和 ICANN 员工清楚了解请求人的争议历史。更重要的是,董事会赞同 BAMC 的结论,即请求人的历史(无论它有多长)对于二次请求来说并不重要。

12 BAMC 建议,第9-10 页。

13 同上。

14 请求 19-4,第 8 节,第8-11 页。

15 参见 BAMC 建议,第 11-12 页。

16 反驳意见,第 4 页,引述 BAMC 建议第 9 页。

17 同上,第 5 页。

18 推迟申请表,https://newgtlds.icann.org/en/applicants/auctions/date-advancement-postponement-form-09nov17-en.pdf(着重号为原文所有)。

19 BAMC 建议第 10 n.53 条,引述新 gTLD 的拍卖规定(2014 年 11 月 3 日),第 10 节,https://newgtlds.icann.org/en/applicants/auctions/rules-03nov14-en.pdf

20 推迟申请表。

21 董事会确认,拍卖规定指出,在某些情况下,申请人可以通过 ICANN 客户门户提交推迟申请,而不必使用推迟申请表。拍卖规定第 10 节。但是,拍卖规定对推迟拍卖的论述并未表明 ICANN 可能会批准多次推迟同一字符争用集。参见内容同上。董事会得出结论,拍卖规定不包含支持或允许多次推迟字符争用集拍卖的规定。

22 反驳意见,第 10 页。

合法权利异议23 2013 年 3 月的专家裁决合法权利异议,https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0009.pdfhttps://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0010.pdfhttps://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0011.pdf。Merck KGaA 于 2016 年 8 月提交重审请求 16-12 时,请求人再次收到提醒,他们最终需要通过达成私下解决方案或拍卖解决字符争用集问题。BAMC 建议,第11-12 页。

24 反驳意见,第6-7 页。

25 同上。

26 拍卖规定第 10 节;另请参见推迟申请表。

27 反驳意见,第 7 页,引述 BAMC 建议第 14 页。

28 同上。

29《ICANN 章程》第 1 条第 1.2(a) 款。

30 反驳意见,第 7 页。

31 请求 19-4,第 8 节,第8、10、13、14 页。

32 BAMC 建议,第 15 页。

33 反驳意见,第 8 页。

34 反驳意见,第 10 页。

35 同上。

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