Skip to main content
Resources

批准的会议记录 | ICANN 董事会例行会议

本页面还提供其他语种:

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

  1. 认可议程:
    1. 对重审请求 17-4 的考量
  2. 主要议程:
    1. 请求政府咨询委员会就关于亚马逊所申请域名的建议提供新的或额外信息
    2. 请求将详尽 WHOIS 共识性政策的合规性执行推迟 180 天
    3. 针对 IDN ccTLD 快速通道流程中字符串相似度审核的改进

 

  1. 认可议程:

    1. 对重审请求 17-4 的考量

      鉴于 dotgay LLC 和 DotMusic Limited(下称"请求人")提出了重审请求 17-4(下称"请求 17-4"),对 ICANN 组织对于请求人根据 ICANN 记录信息披露政策索要社群优先评估 (CPE) 流程审核相关文件的请求的回应提出质疑。

      鉴于董事会问责机制委员会 (BAMC) 之前已经决定,请求 17-4 的理由充分并将请求提交给监察官,供其按照 ICANN 章程第 4 条第 4.2(j) 和 (k) 款的规定审核和考量。

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

      鉴于 BAMC 已考量请求 17-4 的益处及所有相关材料,并已建议拒绝请求 17-4,依据是请求 17-4 并未提供正当的重审依据,董事会同意此建议。

      鉴于董事会还考量了请求人对 BAMC 关于请求 17-4 的建议的反驳,并认为这些反驳无法为重审提供其他论据或证据支持。

      第 2017.10.29.01 号决议:董事会采纳 BAMC 关于请求 17-4 的建议 [PDF, 273 KB]。

      第 2017.10.29.01 号决议的理由

      1. 摘要

        请求人 dotgay LLC(下称"dotgay")和 DotMusic Limited(下称"DotMusic")分别提交了 .GAY 和 .MUSIC 的社群申请;这两项申请均参与了社群优先评估,但均未通过评估。2015 年 10 月,dotgay 寻求重审 CPE 结果(下称"请求 15-21"),1但董事会治理委员会 (BGC)2 拒绝了该请求。32016 年 2 月,dotgay 寻求重审遭 BGC 拒绝的请求 15-21(参见"请求 16-3")。42016 年 2 月,DotMusic 寻求重审 CPE 决定和批准 DotMusic 的申请(下称"请求 16-5")。5

        随后,ICANN 董事会指示总裁兼首席执行官、或其代理人对 ICANN 组织与 CPE 提供商之间的交流流程进行审核(下称"CPE 流程审核")。之后,BGC 决定,CPE 流程审核还应包括 CPE 提供商评估所依据的参考资料,这些参考资料是有关 CPE 的待定重审请求的主题。这八项有关 CPE 的待定重审请求被 BGC 暂且搁置,包括请求 16-3 和 16-5,CPE 流程审核尚待完成。

        2017 年 6 月 10 日,请求人提交了一项联合 DIDP 请求,旨在索要与 CPE 流程审核有关的文件和信息,包括请求人已在之前的 DIDP 请求中索要的一些文件和信息。(参见"联合 DIDP 请求",参考资料附件 E。)ICANN 组织的回应(对联合 DIDP 请求的回应,参考资料附件 F)解释称,除了某些适用 DIDP 定义的不披露条件(下称"不披露条件")的文件外,其他所有回应文件均已发布和确定,以回应请求人之前的 DIDP 请求。6参见内容同上。)对联合 DIDP 请求的回应中提供了对之前 DIDP 请求的回应超链接,这反过来确定和提供了公开可用的回应文件的超链接。(参见内容同上,第 2 页。)对联合 DIDP 请求的回应进一步解释称,有两项内容(第 2 和第 4 项)并未寻求 ICANN 内现有的记录信息。(参见内容同上。)此外,对联合 DIDP 请求的回应解释称,ICANN 组织评估了适用不披露条件的回应文件,以确定披露这些文件的公共利益是否大于披露所带来的危害,结果确定在任何情况下,披露信息的公共利益均小于披露文件所带来的危害。(参见内容同上,第 3 页。)

        之后,请求人提交了重审请求 17-4(下称"请求 17-4"),对联合 DIDP 请求的回应提出质疑。(参见"请求 17-4",参考资料附件 A。)请求人认为,重审对联合 DIDP 请求的回应存在正当理由,因为 ICANN 组织违背了 ICANN 的核心价值,以及关于无差别对待、透明度和问责制的现有 DIDP 与章程。(参见内容同上,第§ 8 款,第 21 页。)

        BAMC 考量了请求 17-4 以及所有相关材料,并建议董事会拒绝请求 17-4,因为该请求没有提供正当的重审依据,具体原因列于 BAMC 有关重审请求 17-4 的建议(下称"BAMC 建议")中,该建议已纳入考量并纳入此决议。(参见"BAMC 建议"[PDF, 273 KB],参考资料附件 D。)

        2017 年 10 月 26 日,请求人根据 ICANN 章程第 4 条第 4.2(q) 款的规定提交了对 BAMC 建议的反驳(下称"反驳")。(参见"反驳",参考资料附件 G。)请求人认为:(1) 请求 17-4 在重审流程范围内,因为"重审流程允许审核作为或不作为 — 而非仅审核采取行动所使用的流程";(2) "DIDP 与 ICANN [组织]的承诺和核心价值有关,对透明度提出了要求";且 (3) ICANN 组织在回应联合 DIDP 请求时违背了其透明度、问责制和公正性承诺。(参见内容同上。

      2. 事实和建议

        完整的事实背景参见"BAMC 建议"[PDF, 273 KB],董事会审核并考量了该建议,并将建议纳入此决议。

        2017 年 10 月 11 日,BAMC 建议拒绝请求 17-4,依据是请求 17-4 并未提供正当的重审依据,具体原因列于 BAMC 建议 [PDF, 273 KB] 中,董事会已将其纳入考量并纳入此决议。

        2017 年 10 月 26 日,请求人根据 ICANN 组织章程第 4 条第 4.2(q) 款的规定提交了对 BAMC 建议的反驳,董事会也考量了该反驳。

      3. 问题

        要重审的问题如下7

        • ICANN 组织在回应联合 DIDP 请求时是否遵守现有 ICANN 政策。
        • ICANN 组织在回应联合 DIDP 请求时是否遵守其核心价值、使命和承诺。
      4. 评估重审请求的适用标准

        ICANN 章程第 4 条第 4.2(a) 和 (c) 款的相关部分规定,如果由于下列因素而受到负面影响,任何实体都可以提出请求,要求"对 ICANN 的作为或不作为进行重审或审核:

        1. 董事会或工作人员所采取的一项或多项违背 ICANN 使命、承诺、核心价值和/或现有 ICANN 政策的行动或不作为;
        2. 在董事会或工作人员所采取或拒绝采取的一项或多项行动或不作为中,没有考虑到某些重要信息,但以下情况例外:请求人本应在采取行动或拒绝采取行动时,将某些信息提交给董事会或工作人员进行考虑,但实际上并没有提交;或
        3. 董事会或工作人员在依赖错误或不准确相关信息的情况下采取的一项或多项行动或不作为。

        (ICANN 章程,2017 年 7 月 22 日,第 4 条第 4.2(a) 和 (c) 款。)根据章程第 4 条第 4.2(k) 款的规定,如果 BAMC 确定该请求的理由充分,请求将被提交给监察官,供其审核和考量。(参见内容同上,第 4.2(l) 款。)如果监察官回避此问题,则 BAMC 应在没有监察官参与的情况下审核请求,并向董事会提供建议。(参见内容同上,第 4.2(l)(iii) 款。)请求人可以针对 BAMC 的建议提出反驳,前提是反驳:(i)"仅限于反驳或针对 BAMC 的建议中提出的问题;且 (ii) 不得提供新的证据支持请求人在原重审请求中提供的论据,这些证据本应由请求人在最初提交重审请求时提供。"(参见内容同上,第 4.2(q) 款。)如果 BAMC 建议且董事会确定,提出请求的一方不满足章程中规定的重审标准,则拒绝重审 ICANN 的作为或不作为的请求是适当的。(参见内容同上,第 4.2(e)(vi)、(q) 和 (r) 款。)

      5. 分析和理由

        董事会审核并充分考量了请求 17-4 以及所有相关材料,包括 BAMC 建议。董事会认为 BAMC 建议 [PDF, 273 KB] 中的分析是合理的,该建议已纳入此决议。董事会还考量了请求人对 BAMC 建议的反驳。董事会认为,反驳并未提出支持重审的论据或事实。

        1. ICANN 组织在回应联合 DIDP 请求时遵守现有政策与程序。

          BAMC 认为对联合 DIDP 请求的回应符合适用政策与程序,且董事会也同意这一点。(BAMC 建议 [PDF, 273 KB],第16-27 页。)在回应根据 DIDP 提交的文件索要请求时,ICANN 组织遵守"ICANN 记录信息披露政策 (DIDP) 请求的回应流程"(下称"DIDP 回应流程")。(参见"DIDP 回应流程"[PDF, 59 KB]。)DIDP 回应流程规定,"在收到 DIDP 请求后,ICANN 工作人员应对请求执行审核,并确定索要的记录信息...,与...相关工作人员面谈,并彻底搜索可回应 DIDP 请求的文件。"(参见内容同上。)对收集的文件进行回应性审核后,还应审核确定这些识别为可回应该请求的文件是否适用 DIDP 网页上所列的任何不披露条件,网址:https://www.icann.org/resources/pages/didp-2012-02-25-en。如果适用,则应执行进一步审核,以确定在特殊情况下,披露这些记录信息的公共利益是否大于披露信息可能带来的危害。(参见"DIDP 回应流程"[PDF, 59 KB]。)

          对联合 DIDP 请求的回应解释称,除了某些适用不披露条件的文件外,其他所有回应文件均已发布和确定,以回应请求人之前的 DIDP 请求,这与 DIDP 回应流程一致。(参见"对联合 DIDP 请求的回应"[PDF, 214 KB],第 2 页。)对于第 1 和第 3 项内容,ICANN 组织确定,所有回应记录信息均已在 ICANN 网站上公布,并在回应之前的 DIDP 请求时提供给请求人。(参见内容同上,第 2 款。)对这些请求的 DIDP 回应确定并提供了 21 份公开可用的文件和网站编译文件的超链接,其中包含回应第 1 和第 3 项内容的信息。(参见内容同上。)对联合 DIDP 请求的回应进一步解释称,有两项内容(第 2 和第 4 项)并未寻求 ICANN 内现有的记录信息。(参见内容同上。)尽管有此要求,但 ICANN 组织仍在状态更新和之前的 CPE 流程审核更新中提供了回应第 2 和第 4 项内容的重要信息,并提供了这些更新的超链接。(参见内容同上,第 2-3 款。)此外,对联合 DIDP 请求的回应解释称,回应第 2 和第 4 项内容的一些文件适用某些确定的不披露条件。(参见内容同上。)对联合 DIDP 请求的回应进一步解释称,ICANN 组织按照规定评估了适用不披露条件的回应文件,并确定在任何情况下,披露信息的公共利益均小于披露文件所带来的危害。(参见内容同上,第 3 款。)

          请求人认为重审存在正当理由,因为 ICANN 组织在回应第 1 至 4 项内容时违背了 ICANN 的核心价值,以及关于无差别对待、透明度和问责制的现有 DIDP 与章程。(参见"请求 17-4",第 8 款,第 21 页。)此外,请求人认为,ICANN 组织在回应第 2 和第 4 项内容时关于特定不披露条件的适用性决定为重审提供了正当理由,因为披露这些文件"符合公共利益"。(参见内容同上,第 8 款,第 22 页。)

          BAMC 确定,请求人没有依据支持其观点,因为 ICANN 组织在回应 DIDP 请求时确实遵守了现有政策与程序,且董事会也同意这一点。(参见"BAMC 建议"[PDF, 273 KB],第16-27 页。)请求人并未声称对联合 DIDP 请求的回应违反 DIDP 回应流程,亦未提供任何信息表明 ICANN 组织对联合 DIDP 请求的回应违背 ICANN 的使命、承诺或核心价值。(参见内容同上。)BAMC 进一步认定且董事会同意,ICANN 组织按照规定对适用不披露条件的回应文件的评估符合 DIDP 流程,并确定在任何情况下,披露信息的公共利益均小于披露文件所带来的危害。(参见内容同上,第 21-26 款。)尽管请求人可能认为 ICANN 组织应以其他方式行使自由裁量权,但这并不构成重审依据。

        2. 请求人所提及的 ICANN 承诺与核心价值无支持依据,因此无法为重审对联合 DIDP 请求的回应提供支持。

          请求人认为,ICANN 组织在回应联合 DIDP 请求时违背了以下承诺与核心价值:ICANN 章程第 1 条第 1.2(a)、第 1.2(a)(v) 和第 1.2(a)(vi) 款,以及第 3 条第 3.1 款。(参见"请求 17-4",第 6 款,第5-7 页。)但是,正如 BAMC 所认定,请求人并未在请求 17-4 中解释这些承诺与核心价值如何与对联合 DIDP 请求的回应有关,或者 ICANN 组织如何违背这些承诺与核心价值,董事会也对此表示同意。(参见"BAMC 建议"[PDF, 273 KB],第26-27 页。)同样地,请求人所列举的承诺与核心价值没有为重审提供依据。

        3. 反驳并未提出支持重审的论据或事实。

          董事会还考量了请求人的反驳,并认为请求人没有提出其他任何支持重审的论据或事实。

          反驳声称:(1) 请求 17-4 在重审流程范围内,因为"重审流程允许审核作为或不作为 — 而非仅审核采取行动所使用的流程";(2) "DIDP 与 ICANN [组织]的承诺和核心价值有关,对透明度提出了要求";且 (3) ICANN 组织在回应联合 DIDP 请求时违背了其透明度、问责制和公正性承诺。(参见"反驳"。)

          对于请求人声称的第一点,董事会考量了请求 17-4 及所有相关材料、BAMC 建议和反驳,并认为重审不存在正当理由。"如果由于下列因素而受到负面影响,请求人可通过重审请求流程寻求对 ICANN 组织的作为或不作为进行重审:…董事会或工作人员所采取的一项或多项违背 ICANN 使命、承诺、核心价值和/或现有 ICANN 政策的行动或不作为。"(ICANN 章程,第 4 条第 4.2(c)(i) 款。)如果请求人能够证明该行动或不作为违背"ICANN 使命、承诺、核心价值和/或现有 ICANN 政策",那么重审便是合理的。(参见内容同上另请参见:例如,董事会有关请求 17-3 的决定:https://www.icann.org/resources/board-material/resolutions-2017-09-23-en#2.b;董事会有关请求 17-1 的决定:https://www.icann.org/resources/board-material/resolutions-2017-06-24-en#2.d。)8请求人在提出重审请求质疑 ICANN 组织的作为或不作为结果时,如果除了对该结果不满意之外,并没有提出任何支持性证据,那么该请求不满足重审标准。同样地,如果重审请求没有解释质疑的行动或不作为如何违背 ICANN 组织的使命、承诺、核心价值和/或现有 ICANN 政策等,那么该重审请求也是不合理的。

          请求人称,"重审请求为重新审查某项行动或不作为提供了机会。"(反驳,第 3 页。)此请求正体现了这一点。实际上,尽管请求人未能证明 ICANN 组织的行动或不作为违背了其使命、承诺、核心价值和/或现有 ICANN 政策,但 BAMC 评估了对联合 DIDP 请求的回应,以确定是否存在违规行为。BAMC 认定,ICANN 组织的回应行为与其使命、承诺、核心价值和现有政策一致,且董事会也同意这一点。(BAMC 建议,第16-27 页。)

          其次,请求人反对称,"ICANN 必须在 DIDP 期间遵循其承诺与核心价值",因为"DIDP 与这些承诺及核心价值密切相关。"(反驳,第4-5 页。)但是,对联合 DIDP 请求的回应并未遵守 ICANN 组织的承诺与核心价值。DIDP 通过设定程序来履行支持透明度和问责制的 ICANN 承诺与核心价值,除非出于保密性的迫切原因,公众可通过该程序获得有关 ICANN 组织运营的文件,以及 ICANN 组织所有、保管或控制的文件。(参见 DIDP:https://www.icann.org/resources/pages/didp-2012-02-25-en)但是,任何支持透明度和问责制的 DIDP 或 ICANN 组织承诺与核心价值均不得规定 ICANN 组织有义务向公众公布 ICANN 组织所有的每一份文件。正如今年初 Amazon EU S.A.R.L. 诉 ICANN 独立审核流程小组案的专家组所称:

          尽管 ICANN 的透明度承诺有此要求,但 ICANN 章程及其发布实践都承认,在某些情况下,非公开信息(例如,与 ICANN 审议流程相关的内部工作人员沟通...)可能包含应适当保护不被披露的信息。

          (Amazon EU S.A.R.L. 诉 ICANN 案,ICDR 案例号:01-16-000-7056,程序令 [2017 年 6 月 7 日],第 3 页。)ICANN 组织章程强调需要平衡利益冲突(例如,透明度与隐私性之间的冲突),指出"当必须在一项核心价值与另一项可能与之冲突的核心价值之间进行平衡时,平衡测试结果必须有利于通过自下而上的多利益相关方流程制定政策或最大程度地满足 ICANN 使命的要求。"(ICANN 章程,第 I 条第 1.2(c) 款。)DIDP 制定了一项隐私问题平衡(例如,特权与保护审议流程之间的平衡)测试,该测试支持 ICANN 组织以高效、卓越的方式运营以及"力争在不同利益相关方的利益之间达到合理的平衡,同时避免操纵行为"的核心价值,但反对透明度核心价值。(参见内容同上,第 1.2(b)(v) 和第 1.2(b)(vii) 款。)因此,ICANN 组织可以根据 DIDP 的规定,适当地行使其自由裁量权,以在不违背其透明度承诺的情况下,确定某些文件不适合披露。

          其次,请求人声称,对联合 DIDP 请求的回应违背了 ICANN 支持透明度、公正性和问责制的承诺与核心价值。(反驳,第9-10 页。)董事会认为,这些论据没有支持依据。

          关于 ICANN 的透明度承诺,请求人认为,ICANN 组织应披露所请求的全部文件,或者至少应"确定适用[不披露条件]的文件,并解释如何适用不披露条件。"(参见内容同上,第 6 页。)如上所述,ICANN 组织认为所请求的某些文件适用 DIDP 不披露条件,这符合现有政策与程序,包括 ICANN 的透明度承诺。此外,董事会还认为,在回应联合 DIDP 请求流程时,ICANN 组织无需确定适用于所保留的每一份文件的不披露条件;此要求的确可能为 ICANN 带来不必要的负担。在此,BAMC 充分地解释了不披露条件如何适用于 ICANN 组织确定为不适宜披露的文件。具体而言,BAMC 的解释与对联合 DIDP 请求流程的回应一致,称所请求的资料包含内部草案、可能损害与 CPE 流程审核有关的审议和决策流程诚信的资料,以及适用律师-委托人或其他特权的资料。(BAMC 建议,第23-24 页。)最后,请求人并未表明 ICANN 组织没有遵守 DIDP,或者其对联合 DIDP 请求的回应违背 ICANN 支持透明度、公正性和问责制的承诺与核心价值。

          请求人还认为,根据 ICANN 支持透明度和公正性的承诺与核心价值,即使某些不披露条件适用,ICANN 组织仍需披露所要求的资料,因为 CPE 审核流程"对请求人及其他方至关重要",且所要求的文件"与公共利益密切联系",而且请求人质疑"披露[这些]文件的危害极小。"(反驳,第6-8 页。)"公共利益"并非根据任何实体是否对某个问题"感兴趣"而定,而是根据某个行动在整体上是否符合"公共利益"而定。此外,DIDP 允许 ICANN 组织酌情决定"在特殊情况下,...披露信息的公共利益是否大于披露可能带来的危害。"(DIDP 网页:https://www.icann.org/resources/pages/didp-2012-02-25-en。)

          正如对联合 DIDP 请求的回应中所解释,ICANN 组织评估了适用不披露条件的文件,以确定披露这些文件的公共利益(包括透明度和公正性问题)是否大于披露可能造成的危害,结果认定在这些情况下,公共利益并不大于披露可能造成的危害。(参见"对联合 DIDP 请求的回应",第 2-3 页。)如上所述,请求人认为,ICANN 组织应以其他方式行使自由裁量权,但这并不构成重审依据,因为请求人并未表明 ICANN 组织以任何方式违背 DIDP。

          请求人还认为,ICANN"阻断了获取其他[有关 CPE 流程审核]的信息的可能性,这明显违背其透明度承诺与核心价值。(反驳,第 7 页。)同样地,请求人认为,ICANN 组织的决议极不公平,"限制了...对有关 [CPE 流程审核]的信息的访问,这使受影响的各方处于不知情中,并引起若干与独立审核本身的诚信有关的危险信号,且"ICANN 禁止了互联网社群知情参与 [CPE 流程审核]。"(参见内容同上,第9-10 页。)董事会称,BGC 和 ICANN 组织对 CPE 流程审核进行了多次更新,包括 2017 年 9 月 1 日的更新。(https://www.icann.org/news/announcement-2017-09-01-en。)此外,正如 2017 年 9 月 1 日的更新所述,CPE 流程审核仍在进行。CPE 流程审核完成后,ICANN 社群(包括请求人)将可获得其他信息。

          此行动在 ICANN 的使命范围内,且符合公共利益,因为必须确保 ICANN 在履行使命时,负责确保社群依照企业设立章程、ICANN 章程及其他现有程序运作,这可以通过制定适当的流程实现,通过该流程,任何在很大程度上受 ICANN 董事会或工作人员的行动影响的个人或实体都可以要求对董事会所采取的行动或不作为进行重审。

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

          此项决议体现了组织管理职能,无需征询公众意见。

  2. 主要议程:

    1. 请求政府咨询委员会就关于亚马逊所申请域名的建议提供新的或额外信息

      鉴于 Amazon EU S.à.r.l.(下称"亚马逊")诉 ICANN 独立审核流程 (IRP) 案的最终声明于 2017 年 7 月 11 日发布。

      鉴于在最终声明中,小组建议董事会"立即重新评估亚马逊的申请"并"进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请"。(最终声明第 125 段。)

      鉴于根据适用版本章程第 IV 条第 3.21 款的规定,董事会在 2017 年 9 月 23 日召开的会议上考量了最终声明,并确定需要对小组不具约束性的建议进行进一步考量,即小组建议董事会"立即重新评估亚马逊的申请"并"进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请"。

      鉴于董事会要求董事会问责机制委员会 (BAMC) 审核并考量小组的建议,即董事会"立即重新评估亚马逊的申请"并"进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请",为董事会提供选择方案来考量如何处理小组的建议。

      鉴于 BAMC 已建议董事会询问政府咨询委员会 (GAC) 是否:(i) 希望针对 GAC 关于亚马逊申请不应继续的建议,向董事会提供与"基于优点的公共政策理由"相关的信息;或 (ii) 针对 GAC 关于亚马逊申请不应继续的建议,希望向董事会提供任何其他新的或额外信息。

      兹此发布第 2017.10.29.02 号决议:董事会询问 GAC 是否:(i) 希望针对 GAC 关于亚马逊申请不应继续的建议,向董事会提供与"基于优点的公共政策理由"相关的信息;或 (ii) 针对 GAC 关于亚马逊申请不应继续的建议,希望向董事会提供任何其他新的或额外信息。

      第 2017.10.29.03 号决议:董事会询问 GAC 是否希望向董事会提供任何新的或额外信息(如上所要求),并要求其在计划于 2018 年 3 月 10-15 日召开的 ICANN 第 61 届会议结束前提供此类信息,以协助董事会进行适当、及时的考量。

      第 2017.10.29.02 – 2017.10.29.03 号决议的理由

      Amazon EU S.à.r.l.(下称"亚马逊")向独立审核流程 (IRP) 提起了诉讼,质疑新 gTLD 项目委员会 (NGPC) 2014 年 5 月 14 日的决定,即接受政府咨询委员会 (GAC) 关于三项亚马逊申请不应继续的共识性建议。(第 2014.05.14.NG03 号决议,参见 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b。)

      亚马逊申请了 .AMAZON 及其同等中文和日文域名(下称"亚马逊申请"),申请通过了初始评估(参见 https://newgtlds.icann.org/sites/default/files/ier/bqe3so7p3lu2ia8ouwp7eph9/ie-1-1315-58086-en.pdf [PDF, 46 KB])。在回应亚马逊申请时,巴西和秘鲁政府根据《申请人指导手册》的规定,通过 GAC 提交了一份提前警告,该警告得到了玻利维亚、厄瓜多尔和圭亚那的支持,相关政府在该警告中表示:"若向私营公司授予这一特殊 gTLD 的专有权,则将无法将此域名用于与保护、推广亚马逊生物群落以及与提高人们对相关问题认识有关的公共利益事业。同时还会阻碍利用此域名将与该地区居民相关的网页集中起来。"(提前警告,参见 https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB]。)

      GAC 在北京公报(2013 年 4 月)中表明其需要进一步考量亚马逊申请后,其在德班公报(2013 年 7 月 18 日)中向 ICANN 董事会提出了共识性建议(下称"GAC 建议"),即亚马逊申请不应继续(https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon)。

      2014 年 5 月 14 日,董事会(通过 NGPC)采纳了 GAC 建议,并指示 ICANN 停止亚马逊申请。(第 2014.05.14.NG03 号决议,参见 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b。)NGPC 的决定不会影响亚马逊和 GAC 成员为就相关问题展开对话而作出的持续努力。

      2016 年 3 月,亚马逊对 ICANN 董事会第 2014.05.14.NG03 号决议启动独立审核,该决议指示亚马逊申请不应继续。

      2017 年 7 月 11 日,IRP 小组(下称"小组")在亚马逊 IRP 中发布了其最终声明(https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11jul17-en.pdf [PDF, 294 KB])。下文概述了小组的调查结果和建议,完整内容参见 https://www.icann.org/resources/pages/irp-amazon-v-icann-2016-03-04-en

      在一项 2-1 决定中,小组宣布亚马逊为胜诉方,并声称"董事会通过 NGPC 所采取的行动不符合企业设立章程、ICANN 章程和《申请人指导手册》,因为 NGPC […]完全尊重 [GAC] 关于其建议是否具备有依据的公共政策理由的共识性建议,因此没有履行其职责,没有独立评估和决定是否存在有效且以绩效为基础的公共政策利益支持 GAC 的共识性建议"。(最终声明第 2 段。)小组进一步声称"ICANN 应承担此 IRP 的费用以及 IRP 提供商的费用",并且"应补偿亚马逊 $163,045.51 美元。"(最终声明第 126 段。)

      此外,小组建议董事会"立即重新评估亚马逊的申请"并"进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请"。如果董事会决定亚马逊申请不应继续,小组表示"董事会应解释支持该决定的原因","仅 GAC 共识性建议无法代替董事会通过合理分析作出的独立且客观的决定"。(最终声明第 125 段。)或者,如果董事会决定亚马逊申请应继续,小组建议 ICANN"在发布此最终声明后六十 (60) 天内"与 GAC"会面协商"。(最终声明第 125 段。)在得出结论的过程中,小组表示,"基于此 IRP 的事实,适用于 GAC 的程序公正性义务至少应要求 GAC 允许可能受到不利影响的一方发表书面声明或意见,之后再决定是否发布共识性建议反对申请;董事会有义务确保作为 ICANN 选区机构的 GAC 具备相关程序并遵循这些程序"。(最终声明第 94 段。)

      小组进一步认为,"尽管无需提供任何原因或理由,但 GAC 共识性建议必须基于有依据的公共利益问题,且此公共利益依据必须通过或者可以通过完整的记录在 NGPC 前确定"。(最终声明第 103 段。)小组称,"NGPC 尊重 GAC 关于存在有效公共政策问题的共识性建议,这样一来,NGPC 便没有履行其在 ICANN 治理文件下的义务,没有就是否允许继续申请做出客观独立且基于绩效的决定"。小组进一步表示,"NGPC 没有独立地评估和阐明 GAC 建议存在有依据的公共政策理由,这实际上为 GAC 共识性建议创造了一个结论性或不容置疑的推定"。(最终声明第 116 段。)

      根据适用版本章程第 IV 条第 3.21 款的规定,董事会在 2017 年 9 月 23 日召开的会议上考量了最终声明,并确定需要对小组不具约束性的建议进行进一步考量等事宜,即小组建议董事会"立即重新评估亚马逊的申请"并"进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请"。董事会要求 BAMC 审核并考量小组的建议,并提供选项供董事会在处理小组建议时考量。

      在审核并考量最终声明、小组建议及所有相关材料后,董事会问责机制委员会 (BAMC) 认为,如果 GAC 能够选择针对其关于亚马逊申请不应继续的建议提供任何新的或额外信息,则将对其十分有益。董事会认为,任何新的或额外信息都将有助于董事会按照小组的建议,对亚马逊申请执行全面的重新评估。因此,BAMC 建议董事会针对 GAC 关于亚马逊申请不应继续的建议,询问 GAC 是否希望向董事会提供任何新的或额外信息。

      董事会认识到这项决定的重要性,并希望阐明,它会非常认真地对待所有 ICANN 问责机制的结果,这进一步体现为建立新的 BAMC 以及将小组建议提交给 BAMC。

      此项决定在 ICANN 的使命范围内,且有助于促进公共利益,因为 ICANN 考量此问题的最终结果是协调域名在域名系统 (DNS) 根区中的分配与指定的关键方面。此外,董事会的决定符合公共利益,考量并平衡了解决未决 gTLD 争议、尊重 ICANN 问责机制和咨询委员会与遵守申请人指导手册中规定的政策与程序的目标,这些目标通过自下而上、基于共识的多利益相关方流程,结合社群意见,经过多年制定而成。

      此项决定预计不会对 ICANN 组织造成任何直接财务影响。该行动将不会对域名系统的安全、稳定或弹性产生任何影响。

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

    2. 请求将详尽 WHOIS 共识性政策的合规性执行推迟 180 天

      鉴于详尽 WHOIS 共识性政策要求,最迟自 2018 年 5 月 1 日起,所有新域名注册均必须作为"详尽"域名提交给注册管理机构,且 2019 年 2 月 1 日前,现有域名的所有相关注册数据均必须从"简略"迁移至"详尽"。

      鉴于从简略迁移至详尽注册模式需要注册服务机构修改其向注册服务机构提交注册数据所使用的系统。

      鉴于注册服务机构利益相关方团体表达了担忧,即执行此类修改可能会暂停有关欧盟《通用数据保护条例》(GDPR) 问题的决议,这可能需要进一步修改系统。

      鉴于在为完成部署以接受详尽 WHOIS 数据做准备期间,Verisign, Inc. 提议对 .COM 和 .NET 注册管理机构-注册服务机构协议进行修改,为 Verisign 提供必要的法律框架,便于其开始接受注册服务机构将详尽数据传送至注册管理机构。

      鉴于 ICANN 组织一直在促进 Verisign 与注册服务机构利益相关方团体之间展开讨论,以就注册管理机构-注册服务机构协议修订提案达成一致,从而执行详尽 WHOIS 共识性政策。

      鉴于 Verisign 与注册服务机构利益相关方团体需要更多时间才能就执行详尽 WHOIS 共识性政策所适用的注册管理机构-注册服务机构协议修订提案达成一致。

      鉴于解决有关将 GDPR 应用于 WHOIS 数据的问题需要更多时间。

      兹此发布第 2017.10.29.04 号决议:授权总裁兼 CEO 或其指定人员将详尽 WHOIS 共识性政策的合规性执行推迟 180 天,以便为注册服务机构和 Verisign 提供更多时间,供其就执行此项政策所适用的注册管理机构-注册服务机构协议所需的修订达成一致,并使注册服务机构能够做出必要的系统更改,以确保从简略到详尽的迁移,以及为符合 GDPR 所需的其他更改(如有)。

      第 2017.10.29.04 号决议的理由

      详尽 WHOIS 共识性政策要求,最迟自 2018 年 5 月 1 日起,注册服务机构应向 .COM、.NET 和 .JOBS 注册管理机构提交所有新域名注册的详尽注册数据。该政策还要求,2019 年 2 月 1 日前,所有现有域名注册数据均应从简略迁移至详尽。在为完成部署以接受详尽 WHOIS 数据做准备期间,.COM 和 .NET 的注册管理运行机构兼 .JOBS 的后端注册管理机构服务提供商 Verisign 提议对 .COM 和 .NET 注册管理机构-注册服务机构协议进行修改,为 Verisign 提供必要的法律框架,便于其开始接受注册服务机构将详尽数据传送至注册管理机构。

      ICANN 组织遵循了其已发布的注册管理机构-注册服务机构协议修订程序,并已将提议的修改提交至注册管理机构利益相关方团体供其审核。注册服务机构利益相关方团体提出了关于批准修订提案的疑虑,其依据是与 2018 年 5 月 25 日生效的欧盟《通用数据保护条例》(GDPR) 相关的问题。因此,程序中概述的下一步骤是 ICANN 组织与注册管理运行机构和注册服务机构利益相关方团体协商,解决这些疑虑。

      过去数月以来,ICANN 组织一直在促进 Verisign 与注册服务机构利益相关方团体之间展开讨论,以就注册管理机构-注册服务机构协议修订提案达成一致,但双方尚未达成一致。此外,由于即将实施《通用数据保护条例》,ICANN 组织正研究其与注册管理机构和注册服务机构之间的协议是否存在潜在违规问题。ICANN 组织正与注册管理机构、注册服务机构及各利益相关方合作,以了解这些潜在违规问题。根据初步审核与沟通,包括与一些数据保护机构之间的沟通,ICANN 组织意识到,遵守 GDPR 将对 WHOIS 系统产生一定影响。

      2017 年 6 月 29 日,ICANN 组织批准了 Verisign 关于将该政策延期至可选里程碑日期的请求,以便注册服务机构能够开始自愿向注册管理机构提交详尽数据。批准延期的目的在于,为 Verisign、ICANN 和注册服务机构利益相关方团体提供更多时间,让他们继续开展讨论,以期达成解决方案,同时仍然采取合理步骤以遵循政策。可选里程碑日期 2017 年 8 月 1 日被推迟至 2017 年 11 月 29 日。

      为了使注册服务机构和 Verisign 有更多时间,就为执行此项政策而需对注册管理机构-注册服务机构协议作出的修订达成一致,董事会目前正采取行动,授权 ICANN 总裁兼首席执行官将详尽 WHOIS 政策的合规性执行推迟 180 天。推迟执行期限还将使 ICANN 组织能够继续与欧洲社群(包括欧盟第 29 条数据保护工作组)、数据保护机构、缔约方及其他有关的利益相关方合作,以便更好地了解 GDPR 的相关方面以及 GDPR 对 ICANN 组织的工作、政策及其与注册管理机构和注册服务机构之间的合同有何潜在影响,包括详尽 WHOIS 政策。

      由于董事会的行动,最迟自 2018 年 10 月 28 日起,ICANN 组织将开始该政策的合规性执行,要求注册服务机构向注册管理机构提交所有新域名注册的详尽数据,且在 2019 年 7 月 31 日前,现有域名的所有相关注册数据均须从简略迁移至详尽。注册服务机构开始自愿向注册管理机构提交详尽数据的可选里程碑日期将为 2018 年 5 月 28 日。

      在推迟合规性执行期间,ICANN 组织将继续与 Verisign 和注册服务机构利益相关方团体合作,促进就修订提案展开讨论。ICANN 组织还将向社群提供详尽 WHOIS 政策的最新合规性进展。在延期期间,注册服务机构利益相关方团体表明 [PDF, 43 KB],其将继续与 ICANN 和 Verisign 就 RRA 变更、ICANN 在 GDPR 下的职责以及实施详尽 WHOIS 过渡所需的措施展开合作"。

      董事会对该问题的审议包括但不限于以下重要材料:

      此项行动符合公共利益,因为其有助于确保一致协调地执行 gTLD 政策,并且在 ICANN 协调政策制定与实施的使命范围内。

      董事会的行动预计不会对 ICANN 产生当前预算未预见到的财务影响,并且将不会对域名系统的安全、稳定与弹性产生负面影响。

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

    3. 针对 IDN ccTLD 快速通道流程中字符串相似度审核的改进

      鉴于 ICANN 董事会于 2009 年 10 月 30 日批准了 IDN ccTLD 快速通道流程的最终执行计划 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2)。

      鉴于作为对执行计划审核与更新的一部分,ccNSO 理事会在提出 IDN ccTLD 字符串选择建议后,请求 ICANN 董事会纳入对字符串相似度评估执行两个审核小组流程的建议 (http://ccnso.icann.org/node/38787)。

      鉴于 ICANN 董事会批准了 IDN ccTLD 快速通道流程实施的更新,以实施针对字符串相似度审核的两个审核小组流程。2013 年 6 月 27 日,字符串相似度进阶处理审核小组 (EPSRP) 获得批准,被纳入 IDN ccTLD 快速通道流程,ICANN 组织获指示制定相关指南并相应地更新最终执行计划 (https://www.icann.org/resources/board-material/resolutions-2013-06-27-en#2.a)。

      鉴于 2013 年更新后,应相关申请人的请求,通过 EPSRP 流程评估了快速通道流程中未决的 IDN ccTLD 字符串,EPSRP 针对三个申请的带有评估结果的报告于 2014 年 10 月 14 日发布在 ICANN 网站 (https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en)。其中一项申请收到了独立结果,该结果基于对所申请字符串的大小写形式产生混淆的可能性进行的评估。

      鉴于 IDN ccTLD 快速通道流程第三次年审期间,公众针对试验方法和 EPSRP 所报告结果的相关问题提出了反馈意见,包括对 EPSRP 的独立建议的解读,这些建议与所申请字符串大小写形式的相似度混淆有关 (https://www.icann.org/public-comments/idn-cctld-fast-track-2015-01-15-en)。

      鉴于公众就第三次年审发表意见后,ICANN 董事会于 2015 年 6 月 25 日决定,要求 ccNSO 与 GAC 和 SSAC 等其他利益相关方协商,针对二级字符串相似度审核流程采用的方法提供进一步指南和改进意见 (https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.a)。

      鉴于在回应董事会寻求更多澄清说明的信函时,ccNSO 和 SSAC 于 2017 年 9 月 19 日作出了联合回应,建议更改 IDN ccTLD 快速通道流程的最终执行计划。

      兹此发布第 2017.10.29.05 号决议:董事会感谢 ccNSO、GAC 与 SSAC 协作解决与字符串相似度审核相关的问题,以及制定"就 EPSRP 对 ICANN 董事会的联合 ccNSO SSAC 回应"。

      第 2017.10.29.06 号决议:董事会采纳联合 ccNSO SSAC 回应中的建议,批准修订 IDN ccTLD 快速通道流程的最终执行计划。指示主席兼首席执行官或其指定人员将此修正案纳入董事会早前于 2009 年 10 月 30 日采纳的实施计划(于 2013 年 11 月 5 日修订)中,并尽快实施此修正案。

      第 2017.10.29.05 – 2017.10.29.06 号决议的理由

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

      2013 年 11 月 5 日,ICANN 组织发布了 IDN ccTLD 快速通道流程最终执行计划的更新版本 [PDF, 851 KB],包括字符串相似度进阶处理审核小组 (EPSRP) 指南 [PDF, 86 KB],供其按照董事会于 2013 年 6 月 27 日的决议,针对字符串相似度实施两个审核小组流程。更新后,保加利亚(西里尔文)、欧盟(希腊文)和希腊(希腊文)三位具备资格的 IDN ccTLD 快速通道申请人采用了选项,执行了第二次相似度审核。EPSRP 完成了审核,ICANN 组织于 2014 年 10 月 14 日发布了这些报告

      针对每一项申请,EPSRP 均记录了其有关所申请字符串的调查结果。每一份报告都详细描述了字符串相似度的试验方法和结果。EPSRP 并未根据对字符串大小写形式进行的试验提供每个字符串的汇总结果。EPSRP 认为,从视觉相似性的角度来看,大小写字母是不同的字符实体。而且,既然并无科学或政策依据表明应如何结合 IDN ccTLD 的大小写相似性结果,那么 EPSRP 就只能针对每一种形式提供单独的建议。因此,如果 EPSRP 根据对字符串大小写形式的相似度混淆的不同发现制定独立结果,那么便没有一项机制能够针对 EPSRP 所完成的二级字符串相似度审核推断出一则汇总建议。

      根据 EPSRP 的这一分析经验,在第三次审核 IDN ccTLD 快速通道流程期间,社群提出了公众意见,对 EPSRP 的方案提出了质疑,包括评估独立建议(例如,大写字母而非小写字母中的相似度混淆)。

      为处理这些意见,董事会(通过第 2015.06.25.16 号决议)要求 ccNSO 在咨询 GAC 和 SSAC 等其他利益相关方之后,针对二级字符串相似度审核流程采用的方法(包括解读各项独立建议)提供进一步指导和改进意见,以应用于 IDN ccTLD 快速通道流程中当前和后续的相关案例,并为有关 IDN ccTLD 字符串选择的拟议政策提供信息。

      ccNSO 的相关工作组与 GAC 成员合作,在定稿前发布了其公众意见报告 [PDF, 274 KB]。SSAC 先后在 SAC 084 [PDF, 218 KB]、SAC 088 [PDF, 72 KB] 和 SAC 089 [PDF, 128 KB] 中提出了不同观点。应董事会的要求,ccNSO 和 SSAC 共同制定了一项解决方案,2017 年 9 月 19 日,ccNSO 和 SSAC 主席将此方案作为联合回应 [PDF, 215 KB] 提交给了董事会。

      借助该解决方案,董事会现已完成对快速通道计划的 2015 年审核,并继续按照 ccNSO 与 SSAC 联合回应中的建议,更新 IDN ccTLD 快速通道流程的最终执行计划。解决此问题符合 ICANN 章程第 1.1(a)(i) 款中规定的 ICANN 使命,即:"协调域名在域名系统根区中的分配与指定"。现在,此未决问题已经得到解决,因此可以开始实施规划的审核周期。

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

      SSAC 在 SAC 084 [PDF, 218 KB] 中提供了初步意见,并在 SAC 088 [PDF, 72 KB] 和 SAC 089 [PDF, 128 KB] 中做出了进一步澄清说明,即在提出独立建议的情况下,"如果两种形式均存在混淆问题,则默认结果将拒绝标签",从而保持按照 RFC 6912 将稳健、纳入和稳定原则应用于 EPSRP 等流程。然而,ccNSO 理事会表示,Unicode 技术报告 36:Unicode 安全注意事项称,"在缓存中使用视觉上可能引起混淆的字符通常被夸大了,…[这]导致了一小部分网络钓鱼问题",这些问题可以采用 Unicode 报告中建议的措施解决。在联合回应中,ccNSO 和 SSAC 约定了一项流程,用以解决 SSAC 提出的疑虑,该流程允许请求人提出措施供专家审核,从而确定可能引起混淆的相似性问题是否得到有效缓解。

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

      董事会已审核并协商了各种材料和因素,并在今日采取了行动。相关的重要材料包括但不限于以下文件:

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

      董事会注意到,ccNSO 和 SSAC 成员已合作建立了一项有效的机制,该机制能够解决流程中引起的相冲突的问题。IDN ccTLD 请求人应提出有效的风险缓和措施,以解决 SSAC 早前提出的安全性疑虑。

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

      此决定具有积极影响,因为它澄清了第二次相似度审核指南中的混淆问题,即如果提出独立建议,则允许继续评估 IDN ccTLD 字符串,前提是只要能够确定并实施有效的风险缓和措施。此决定还增加了支持当地互联网用户的其他国家和地区使用 IDN ccTLD 的可能性,以此支持公共利益。

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

      实施此决定后,将产生财务影响,因为 ICANN 组织必须聘用相关专家来审核请求人提出的缓和战略。

      是否存在任何安全、稳定或弹性问题?社群提出了哪些疑虑或问题?

      SSAC 和 ccNSO 的联合回应解释称,有四种方法可以判断所申请的字符串的大小写形式是否存在混淆性相似。其中一种方法是,如果两种形式均不存在混淆性相似,则字符串将通过评估。另外两种方法是,如果小写字母存在混淆性相似,则无论大写字母是否存在混淆性相似,相关的风险均过高且难以缓和,因此字符串无法通过评估。最后一种方法是,如果小写字母不相似,但大写字母存在混淆性相似,则 SSAC 表示适宜采取警告方法。联合回应称,SSAC 认为,风险是一种连续统一体,因此,在最后一种方法中,采取警告方法有助于 IDN ccTLD 请求人提出缓和措施,这些措施应被相关专家视为足以将风险降低至可接受的水平。只有这样,字符串才能通过字符串相似性评估。

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

      初步报告草案拟定后,ccNSO 建议的更新便需要征询公众意见。意见包括 GAC 关于支持结果的回应,以及 SSAC 通过 SSAC 084 作出的回应,及在 SAC 088 和 SAC 089 中作出的进一步回应,即建议了另一种方法。为了应付征询公众意见后体现出的不同观点,ccNSO 和 SSAC 已共同澄清了各自的立场并达成共识,相关信息记录在其提交给董事会的联合回应中。无需进一步征询公众意见即可纳入 ccNSO 与 SSAC 联合回应的 IDN ccTLD 快速通道流程最终执行计划中建议的调整。这属于组织管理职能,无需征询公众意见。


1 BGC 关于请求 15-21 的决定,第 1 页,https://www.icann.org/en/system/files/files/reconsideration-15-21-dotgay-bgc-determination-01feb16-en.pdf [PDF, 272 KB]。

2 2017 年 7 月 22 日之前,BGC 负责审核重审请求。参见 ICANN 章程,2016 年 10 月 1 日,第 4 条第 4.2(e) 款,https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4。2017 年 7 月 22 日之后,董事会问责机制委员会 (BAMC) 负责审核重审请求并向董事会提出建议。参见 ICANN 章程,2017 年 7 月 22 日,第 4 条第 4.2(e) 款,https://www.icann.org/resources/pages/governance/bylaws-en/#article4

3 BGC 关于请求 15-21 的决定,第 1 页。

4 请求 16-3,https://www.icann.org/en/system/files/files/reconsideration-16-3-dotgay-request-17feb16-en.pdf [PDF, 728 KB]。

5 请求 16-5,https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-request-redacted-24feb16-en.pdf [PDF, 1.06 MB]。

6 ICANN 对 DIDP 请求编号 20170505-1 (DotMusic Ltd.) 和 20170518-1 (dotgay LLC) 的回应,已援引并入 ICANN 对 DIDP 请求编号 20170610-1 的回应第 2 页中。

7 正如 BAMC 所称,请求人(通过勾选重审请求表中相应的选框)表明,请求 17-4 寻求对工作人员和董事会行动或不作为进行重审。然而,根据 ICANN 章程第 4 条第 4.2(o) 款的规定,即 BAMC"应...向请求人提供 ICANN 从第三方收集的与重审请求相关的'任何信息'",请求人并未针对 BAMC 的行动或不作为提出任何进一步论据。请求人也并未要求 ICANN 组织就此问题采取任何行动,而是重点关注 ICANN 组织对联合 DIDP 请求的回应。因此,BAMC 将请求 17-4 解读为寻求重审 ICANN 组织对联合 DIDP 请求的回应,而非重审 BAMC 行动或不作为,董事会对此表示同意。(参见"BAMC 建议"[PDF, 273 KB],第12-13 页。)

8 如果请求人表明,董事会或工作人员的行动或不作为没有考虑到重要信息,或者依赖错误或不准确的相关信息,因而使其受到严重影响,那么重审便是合理的。(ICANN 章程,第 4 条第 4.2(c)(ii)、(iii) 款。)

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