Skip to main content
Resources

批准的董事会决议 | ICANN 董事会例行会议

本页面还提供其他语种:

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

  1. 主要议程
    1. .AFRICA 更新
    2. 考虑重新评估 Vistaprint Limited 公司的字符串混淆异议专家裁决

 

  1. 主要议程

    1. .AFRICA 更新

      鉴于在其 2013 年 4 月 11 日发布的北京公报中,政府咨询委员会 (GAC) 依照《申请人指导手册》提出共识性建议,认为 DotConnectAfrica Trust (DCA) 不应继续申请 .AFRICA。

      鉴于 2013 年 6 月 4 日,新 gTLD 项目委员会 (NGPC) 采用“关于 GAC 北京公报中非保护建议的 NGPC 1A 计分卡”,包括接受 GAC 关于 DCA 申请 .AFRICA 的建议。(参阅 https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-04-en#1.a

      鉴于工作人员通知 DCA 并公布“不完整的”初始评估结果,并于 2013 年 7 月 3 日基于 2013 年 6 月 4 日的 NGPC 决议终止 DCA 的 .AFRICA 申请。

      鉴于 2013 年 11 月 25 日,DCA 针对 2013 年 6 月 4 日的决议启动独立审核流程 (IRP),但当时并未设法让 ICANN 延后 ZA Central Registry NPC(以 Registry.Africa 名义进行交易,以下简称“ZACR”)的申请。

      鉴于 2014 年 3 月 24 日,ZACR 签署了 .AFRICA 的注册管理机构协议 (RA)。

      鉴于 2014 年 5 月 13 日,ICANN 停止继续推进 ZACR 的 .AFRICA RA 工作,此前,IRP 小组于 DCA 启动的 IRP 未决之际发布临时声明,指出 ICANN 应终止 ZACR 的 .AFRICA 申请。

      鉴于 2015 年 7 月 9 日,IRP 小组发布其最终声明,并建议 ICANN 继续延后对 .AFRICA gTLD 的授权,以便 DCA 的申请走完新通用顶级域申请流程中的余下部分。(参阅 https://www.icann.org/en/system/files/files/final-declaration-2-redacted-09jul15-en.pdf [PDF,1.04 MB])

      鉴于 2015 年 7 月 16 日,董事会指示总裁兼首席执行官或其指定人员继续延后对通用顶级域 .AFRICA 的授权,并采取所有必要的措施依照既定流程恢复对 DCA 申请 .AFRICA 进行评估。(参阅 https://www.icann.org/resources/board-material/resolutions-2015-07-16-en#1.a

      鉴于 2015 年 9 月 1 日,DCA 的 .AFRICA 申请恢复评估流程。

      鉴于 2015 年 10 月 13 日,基于地理名称专家组对 DCA 申请的审核结果的初始评估报告得以发布,报告表明,DCA 的申请未通过初始评估,但 DCA 因此有资格进行扩展评估;DCA 选择继续完成扩展评估。

      鉴于 2016 年 2 月 17 日,扩展评估报告得以发布,报告表明,DCA 的 .AFRICA 申请的后续评估已结束,由于 DCA 未能提交足以满足 AGB 第 2.2.1.4.3 节中所规定标准的信息和文档,因此不符合进行进一步审核或评估的条件。

      兹此发布第 2016.03.03.01 号决议:董事会授权总裁兼首席执行官或其指定人员依照 ZACR 与 ICANN 签署的注册管理机构协议,继续授权 ZACR 运营 .AFRICA。

      第 2016.03.03.01 号决议的理由

      为了推进 ICANN 的新通用顶级域项目,两个申请人 — DotConnectAfrica Trust (DCA) 和 ZA Central Registry(以 Registry.Africa 名义进行交易,以下简称“ZACR”)申请成为 .AFRICA 这一通用顶级域 (gTLD) 的运营商。鉴于在其 2013 年 4 月 11 日发布的北京公报中,ICANN 政府咨询委员会 (GAC) 依照《新通用顶级域项目申请人指导手册》(以下简称“《指导手册》”)提出共识性建议,认为 DCA 不应继续申请运营 .AFRICA。董事会接受了 GAC 的建议,终止了对 DCA 申请的评估,并且 ICANN 继续与申请运营 .AFRICA 的其他申请人签署了注册管理机构协议。

      DCA 对 GAC 认为 DCA 不应继续完成申请的建议提出质疑,但完成独立审核流程后,董事会接受了该建议。IRP 是《ICANN 章程》中确立的问责机制之一。首先,鉴于 IRP 小组建议 ICANN 在 IRP 结束之前停止继续授权 .AFRICA,只有在 ICANN 与其他 .AFRICA 申请人签署运营 .AFRICA 的注册管理机构协议之后,DCA 才能暂时缓解压力。ICANN 采纳了该建议。其次,DCA 在 IRP 中胜诉,并且 IRP 小组建议 ICANN 恢复对 DCA 申请的评估,并继续延后向已经与 ICANN 签署运营 .AFRICA gTLD 的注册管理机构协议的一方授权 .AFRICA。

      2015 年 7 月 16 日,董事会通过了以下决议:

      第 2015.07.15.01 号决议:董事会考虑了整个声明,并已决定根据该考虑采取以下行动:

      1. ICANN 应继续延后对通用顶级域 .AFRICA 的授权;
      2. ICANN 应允许 DCA 的申请完成下列余下的新 gTLD 申请流程;以及
      3. ICANN 应向 DCA 补偿在声明第 150 段中列出的 IRP 费用。

      参阅 https://www.icann.org/resources/board-material/resolutions-2015-07-16-en#1.a。)

      董事会通过上述决议时,DCA 的 .AFRICA 申请在初始评估 (IE) 期间唯一剩下的评估流程为地理名称专家组审核,因为 DCA 已成功完成 IE 的其他阶段。因此,应工作人员的请求,地理名称专家组于 2015 年 8 月恢复对 DCA 运营 .AFRICA 的申请进行评估。地理名称专家组判定,如《指导手册》第 2.2.1.4 节所定义,.AFRICA 是一个地理名称,但根据 AGB 第 2.2.1.4.3 节之规定,DCA 运营 .AFRICA 的申请并不足以满足相关必要条件,即非洲地理区域内 60% 的公共机构对此表示支持或不反对。

      依照《指导手册》的规定,虽然未能通过 IE,但 DCA 仍有资格选择继续进行扩展评估 (EE),这为 DCA 额外留出 90 天时间来获取通过地理名称专家组审核所需的必要文档。2016 年 2 月 17 日,公布的 EE 结果表明 DCA 再一次未能满足通过地理名称专家组审核的必要条件,因此,DCA 的申请不能进行任何进一步审核。

      既然 DCA 运营 .AFRICA 的申请的 IE 和 EE 均已完成,且两项结果均表明 DCA 未能通过地理名称专家组审核,因此,ICANN 准备继续对 .AFRICA 进行授权,将其授权给已签署运营 .AFRICA 的注册管理机构协议的一方。已签署运营 .AFRICA 的注册管理机构协议的一方迫切希望完成这项工作,以便非洲社群成员可以开始利用此 gTLD。而且,DCA 并没有其他途径可以继续开展新 gTLD 项目,既定的《指导手册》流程也未提供任何进一步延后的理由。

      因此,董事会在此授权总裁兼首席执行官或其指定人员继续对 .AFRICA gTLD 进行授权 — 此前它已指示 ICANN 停止授权。

      采取这项行动符合 ICANN 和整个互联网社群的利益,因为这会在权威根区域中授权 .AFRICA gTLD。由于将产生另一个运营性 gTLD,因此采取这项行动将产生积极的财务影响。该行动不会对域名系统的安全、稳定和弹性产生直接影响。

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

    2. 考虑重新评估 Vistaprint Limited 公司的字符串混淆异议专家裁决

      鉴于 2015 年 10 月 9 日,独立审核流程 (IRP) 小组就 Vistaprint Limited 公司 (Vistaprint) 针对 ICANN 提起的 IRP 发布其最终声明,在该声明中,审核小组宣布 ICANN 胜诉,且董事会的行动未违反《企业设立章程》(《设立章程》)、《章程》或《申请人指导手册》(《指导手册》)。

      鉴于 Vistaprint 明确质疑字符串混淆异议 (SCO) 专家裁决(下称“专家裁决”),审核小组的裁决认为,Vistaprint 的 .WEBS 申请与 Web.com 的 .WEB 申请具有易混淆相似性 (Vistaprint SCO)。

      鉴于 IRP 小组发现,ICANN 没有做出重新评估专家裁决的指示,在此过程中未对 Vistaprint 进行区别对待,因此小组建议董事会判断是否应确立额外的审核机制,以重新评估 Vistaprint SCO。

      鉴于在第 2014.10.12.NG02-2015.10.12.NG03 号决议中,新 gTLD 项目委员会 (NGPC) 自行采取行动,处理了确定不符合新 gTLD 项目和互联网社群最佳利益的数量有限的看似不一致和不合理的 SCO 专家裁决(SCO 最终审核机制)。

      鉴于在评估是否扩大 SCO 最终审核机制的范围时,NGPC 已考量 Vistaprint SCO 专家裁决以及其他专家裁决,并确定不需要重新评估那些专家裁决(包括 Visatprint SCO 专家裁决)。

      鉴于根据 IRP 小组在最终声明中提出的建议,董事会再次评估了是否应采取其他审核机制来重新评估 Vistaprint SCO 及生成的专家裁决。

      兹此发布第 2016.03.03.02 号决议:董事会认定,Vistaprint SCO 专家裁决不存在明显“不一致”或“不合理”,以致于需要重新评估专家裁决的基本异议处理程序。

      兹此发布第 2016.03.03.03 号决议:董事会发现(如其之前发现的),ICANN 有关核心价值及无差别对待的章程条款以及最终声明中提到的特定情况和进展,并不支持对导致 Vistaprint SCO 专家裁决的异议处理程序进行重新评估。

      兹此发布第 2016.03.03.04 号决议:董事会指示总裁兼首席执行官或其指定人员继续处理 .WEB/.WEBS 字符争用集。

      第 2016.03.03.02 – 2016.03.03.04 号决议的理由

      董事会在此采取行动,处理独立审核流程小组在其最终声明中就 Vistaprint Limited 公司 (Vistaprint) 提起的 IRP 提出的建议。具体来说,IRP 小组建议董事会自行决定是否应进行其他审核来重新评估导致“Vistaprint SCO 专家裁决”的 Vistaprint 字符串混淆异议 (SCO)。

      1. 背景

        1. Vistaprint SCO 专家裁决

          参考资料和 IRP 最终声明(参考资料附件 A)中详细介绍了 Vistaprint SCO 专家裁决的背景信息。援引的参考资料应视为全文引用,纳入此决议和理由中。

        2. Vistaprint IRP

          Vistaprint 提出 IRP 请求,对 ICANN 接受 Vistaprint SCO 专家裁决表示质疑。此外,Vistaprint 还对程序、程序的执行以及 ICANN 故意不更正发布不妥当的专家裁决表示质疑。

          2015 年 10 月 9 日,由三名成员组成的 IRP 小组发布其最终声明。经过考量和讨论之后,ICANN 依照《ICANN 章程》第 IV 条第 3.21 款之规定采纳了该小组的结论。(参阅第 2015.10.22.17 – 2015.10.22.18 号决议,地址为:https://www.icann.org/resources/board-material/resolutions-2015-10-22-en#2.d另请参阅 IRP 最终声明,地址为:https://www.icann.org/en/system/files/files/vistaprint-v-icann-final-declaration-09oct15-en.pdf [PDF,920 KB]。)

          此外,审核小组在最终声明中指出,虽然它没有权力要求 ICANN 拒绝专家裁决并允许 Vistaprint 的申请进入下一流程,或要求由三名成员重新评估 Vistaprint SCO 异议。但是,该小组建议:

          根据 ICANN 有关核心价值和无差别对待的章程以及此声明中提到的特定情况和进展,董事会自行判断是否应进行额外审核,以重新评估 Vistaprint SCO 中的[专家]裁决,包括 (i) 有关 Vistaprint 的 .WEBS 申请的 Vistaprint SCO 裁决;(ii) 董事会(和 NGPC)针对单复数形式的 gTLD 的决议;以及 (iii) 董事会授权相同 gTLD 字符串的大量其他单复数形式的决定。

          (最终声明,¶第 196 页,地址为:https://www.icann.org/en/system/files/files/vistaprint-v-icann-final-declaration-09oct15-en.pdf [PDF,920 KB]。)董事会在第 2015.10.22.18 号决议中确认并接受了此建议。(参阅 https://www.icann.org/resources/board-material/resolutions-2015-10-22-en#2.d。)

        3. 易混淆相似性

          1. 通用名称支持组织 (GNSO) 关于易混淆相似性的建议。

            2007 年 8 月,GNSO 就引入新通用顶级域 (gTLD) 提出一组建议(于 2008 年 6 月获得 ICANN 董事会批准)。这些政策建议不包括针对相同字符串的单复数形式提出的具体建议。相反,GNSO 提出的一条建议(建议 2)认为,新 gTLD 字符串不得与现有顶级域名或保留名称具有易混淆相似性。(参阅 GNSO 最终报告:《引入新顶级通用域》,http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm。)

          2. 易混淆相似性问题已获得大家的同意写入《申请人指导手册》,并且会在评估流程中得到解决。

            如与此论文相关的参考资料文档(应视为全文引用,纳入此文中)中详细介绍的,易混淆相似性问题将在评估流程中通过两种方式解决 — 通过字符串相似性审核 (SSR) 流程和字符串混淆异议流程。本初步审核的目的在于,防止相似字符串获得授权,从而造成用户混淆,使人们对 DNS 丧失信心。(参阅模块 2.2.1.1,地址为:https://newgtlds.icann.org/en/applicants/agb/evaluation-procedures-04jun12-en.pdf [PDF,916 KB] 和模块 3.2.1,地址为:https://newgtlds.icann.org/en/applicants/agb/objection-procedures-04jun12-en.pdf [PDF,260 KB]。)SSR 小组未发现任何单词的复数形式与同一单词的单数形式字形相似,反之亦然。(http://newgtlds.icann.org/en/program-status/application-results/similarity-contention-01mar13-en.pdf [PDF,168 KB];http://newgtlds.icann.org/en/announcements-and-media/announcement-01mar13-en。)

          3. 此前,董事会根据政府咨询委员会 (GAC) 的建议,处理了易混淆相似性问题,因为这与相同字符串的单复数形式有关。

            2013 年 6 月 25 日,为响应 GAC 在北京公报中提出的建议,董事会通过新 gTLD 目委员会 (NGPC) 考虑了根中的相同字符串单复数形式的问题。(https://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf [PDF,156 KB]。)NGPC 决定,在处理 GAC 关于相同字符串的单复数形式提出的建议时,无需对《申请人指导手册》中的现有机制做出任何更改。(参阅 https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-25-en#2.d。)如第 2013.06.25.NG07 号决议的理由所述,NGPC 考量了一些主要因素,这包括以下因素:(i) 利用自己的非专家意见推翻专家小组的决定是否会削弱 SSR 评估流程的效力;(ii) 采取行动对计划作出更改是否引起连锁反应、导致所有专家小组决定遭到重议;(iii) DNS 中字符串的现有性质及其带来的正面和负面影响;(iv) 在允许相同字符串同时存在单复数形式的情况下,是否有其他方法可以解决潜在的用户混淆问题;(iv) 《指导手册》模块 3 中制定的 SCO 流程。(参阅 https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-25-en - 2.d。)

            NGPC 确定,《指导手册》制定的机制(SSR 和 SCO)应不做更改,并且仍然是用于判定相同字符串的单复数形式是否可能导致潜在用户混淆的机制。

        4. SCO 最终审核机制

          如本文引用的参考资料详细说明的,NGPC 于 2014 年 10 月 12 日与社群磋商后制定了 SCO 最终审核机制,以处理一组数量非常有限的认为存在不一致和不合理的 SCO 专家裁决。(参阅 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-10-12-en#2.b。)SCO 最终审核机制并不是用于判定根中的相同字符串的单复数形式是否会引起混淆的程序。相反,它是一种为处理两个 SCO 专家裁决(.CAM/.COM 和 .SHOPPING/.通販专家裁决)而制定的机制,在这种情况下,不同专家小组发布与相同字符串相关的相互冲突的专家裁决,导致它们的结果看似不一致和不合理,因此需要进行重新评估。(NGPC 第 2014.10.12.NG03 号决议,地址为:https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-10-12-en#2.b。)NGPC 还确定,.CAR/.CARS 的 SCO 专家裁决不符合新 gTLD 项目和互联网社群的最佳利益,这会导致不同专家小组对就完全相同的字符串提出的异议做出相反的裁决。由于 .CAR/.CARS 字符争用集已在批准 SCO 最终审核机制之前得到解决,因此,它不属于最终审核的内容。(参阅内容同上。

          在其商议过程中,NGPC 考虑后确定,扩大提议的 SCO 最终审核机制的范围,以包括其他专家裁决(如与相同字符串的单复数形式相关的其他 SCO 专家裁决,包括 Vistaprint SCO 专家裁决)的做法并不恰当。在考虑是否应重新评估与相同字符串的单复数形式相关的所有 SCO 专家裁决时,NGPC 表示,它此前已在第 2013.06.25.NG07 号决议中解决了单/复数问题,并确定“不需要对《申请人指导手册》中的现有机制做出任何更改....”(https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-10-12-en#2.b。)

      2. 分析

        1. 董事会已解决与相同字符串的单/复数相关的易混淆相似性问题。

          如上所述,2013 年 6 月,在考虑 GAC 于北京公报中就相同字符串的单复数形式提出的建议时,NGPC 首次考虑了根中相同字符串的单复数形式的问题。NGPC 随后确定,处理该问题不需要对《指导手册》中的现有机制做出任何更改。(https://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf [PDF,156 KB]。)在其评估过程中,NGPC 考虑了申请人对 GAC 建议的回复。NGPC 表示,多数人反对更改现有政策,且指出这一主题已获得大家的同意写入《指导手册》,并且会在评估流程中得到解决。(https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-25-en#2.d。)NGPC 还考虑了二级 DNS 中现有的字符串相似性问题,以及因此产生的任何正面和负面影响。由于当时尚未授权任何新 gTLD,因此,顶级 DNS 中不存在相同字符串的任何单复数形式。到目前为止,已授权 17 对单/复数字符串。董事会尚未发现 DNS 中存在相同字符串的单复数会产生任何影响(正面或负面影响)。因此,存在相同字符串的单复数形式的证据(虽然在 2015 年 6 月尚不存在)应不会影响 NGPC 之前对于此事项的考量。

          如 NGPC 在第 2013.06.25.NG07 号决议中确认的,《指导手册》中用于处理由于相同字符串的单复数形式可能造成的用户混淆问题的现有机制(SSR 和 SCO)足够充分。(https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-06-25-en#2.d。)这些机制旨在解决申请流程开始时的易混淆相似性问题。之所以决定发回 Vistaprint SCO 专家裁决以进行重新评估,是因为如果 DNS 中当前发现存在相同字符串的单复数形式的证据,将会严重削弱已制定的评估流程的预期功能(如果通过 SCO 在申请流程开始时,而不是在证据表明授权了相同字符串的单复数形式之后评估造成混淆的可能性)。(参阅《指导手册》模块 3.5.1。)这样做是对 Vistaprint 进行区别对待,并对其他申请人造成歧视,这可能与《ICANN 章程》相矛盾。

        2. SCO 最终审核机制不适用于 Vistaprint 专家裁决。

          董事会表示,Vistaprint 在 IRP 中辩称,Vistaprint SCO 专家裁决与 .CAM/.COM、.通販/.SHOP、.CARS/CAR 专家裁决同样不合理,因此应发回以根据最终审核机制进行重新评估。(参阅最终声明第¶¶ 93、94 款。)但是,Vistaprint SCO 专家裁决与 .CAM/.COM、.通販/.SHOP、.CARS/.CAR 专家裁决存在明显区别,因此,NGPC 在那些决定中确定的需要重新评估的原因并不适用于 Vistaprint 专家裁决。

          CAM/.COM、.通販/.SHOP、.CARS/.CAR 专家裁决可进行重新评估,因为这些专家裁决包含由不同专家针对相同字符串发布的多个相互冲突的 SCO 裁决,因此导致它们似乎存在不一致和不合理,需要进行重新评估。而且,NGPC 在 SCO 最终审核机制范围内对 .CARS/.CAR 专家裁决的讨论并不是基于单/复数问题,而是因为存在相互冲突的 SCO 专家裁决(两个专家裁决认为 .CARS/.CAR 不存在易混淆相似性,一个专家裁决认为 .CARS/.CAR 存在易混淆相似性。(参阅 Charleston Road Registry, Inc. 与 Koko Castle, LLC SCO 专家裁决,地址为:http://newgtlds.icann.org/sites/default/files/drsp/25sep13/determination-1-1-1377-8759-en.pdf [PDF,196 KB](认为 .CARS/.CAR 之间不可能产生混淆);Charleston Road Registry, Inc. 与 Uniregistry, Corp. SCO 专家裁决,地址为:http://newgtlds.icann.org/sites/default/files/drsp/25oct13/determination-1-1-845-37810-en.pdf [PDF,7.08 MB](认为 .CARS/.CAR 之间不可能产生混淆);以及 Charleston Road Registry, Inc. 与 DERCars, LLC SCO 专家裁决,地址为http://newgtlds.icann.org/sites/default/files/drsp/14oct13/determination-1-1-909-45636-en.pdf [PDF,2.09 MB](认为 .CARS/.CAR 之间可能产生混淆)。)

          其中,对于 NGPC 发回 CAM/.COM、.通販/.SHOP 专家裁决以进行重新评估的决定至关重要的因素,没有任何因素适用于 Vistaprint 专家裁决。Vistaprint SCO 处理程序导致了一个专家裁决,在两个异议中支持 Web.com。不同专家小组就相同字符串发布的任何其他相互冲突的 SCO 专家裁决均未导致不同的结果。一个专家小组集中了所有意见,结合在一起考量了两个异议,并做出了一个有意义且完全明智的决策,即对两个异议做出相同的决定。在这方面,Vistaprint 已获得考虑一个专家小组在两个异议处理程序中提交的证据(已收到 CAM/.COM, .通販/.SHOP 异议以进行重新评估)所带来的相同益处。因此,并不需要重新评估导致 Vistaprint SCO 专家裁决的异议,因为只有让相同专家小组在初审时审核所有相关处理程序,才能取得已经取得的结果。而且,如上所述,NGPC 已经在审议 SCO 最终审核机制的范围时考虑了 Vistaprint SCO 专家裁决,并确定不需要重新评估导致该专家裁决的异议处理程序。因此,虽然 Vistaprint 可能实质上并不赞同该专家裁决,但并没有证据表明它存在“不一致”或“不合理”,因而需要进行重新评估。

          董事会的评估以下列内容为指导:NGPC 在确定最终审核机制的范围时所采用的标准、NGPC 根据第 2013.06.25.NG07 号决议确定是否存在与 TLD 相同的单词的单数和复数形式时所做的考量和决定、GNSO 关于引入新通用顶级域的最终报告、《申请人指导手册》(包括其中用于处理潜在用户混淆所采用的机制)、最终声明中提到的特定情况和进展,以及《章程》第 I 条第 2 款中规定的核心价值。考虑到这些因素,并基于下述原因,董事会得出结论:对导致 Vistaprint SCO 专家裁决的异议处理程序进行重新评估并不适当,因为该专家裁决与 NGPC 之前的定义并不存在“不一致”或“不合理”,也没有任何其他方面需要进行重新评估。

          此外,董事会还考虑了 NGPC 在采纳第 2014.10.12.NG02 – 2014.10.12.NG03 号决议时采用的以下标准:

          • 此时更改《指导手册》来实施审核机制的做法是否恰当。
          • 某些看似不一致的专家裁决是否存在合理依据,特别是为什么要将确定的专家裁决发回给 ICDR,而其他专家裁决则不用。
          • 扩大提议的审核机制的范围,以包括其他专家裁决(如与相同字符串的单复数形式相关的其他 SCO 专家裁决,包括 Vistaprint SCO 专家裁决)的做法是否恰当。
          • 社群就该问题的致函以及社群在 ICANN 会议上表达的意见。

          参阅 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-10-12-en。)此外,董事会还审核并考量了 NGPC 在第 2013.06.25.NG07 号决议中针对存在与 TLD 相同的字符串的单复数形式所采取的行动。

          在其决策过程中,董事会考量并平衡了《章程》第 I 条第 2 款中规定的十一项核心价值。《章程》第 I 条第 2 款规定:“不可避免地会出现某些情况,在这些情况下无法同时完全符合所有十一项核心价值。任何提出建议或做出决定的 ICANN 机构都应当做出判断,确定哪些核心价值最为相关,以及如何将它们应用到当下案例的具体环境中,必要时还要合理权衡一些价值之间的冲突。”(《章程》第 I 条第§ 2 款:https://www.icann.org/resources/pages/governance/bylaws-en/#I。)董事会发现,在这十一项核心价值中,第 1、4、7、8、9 和第 10 项价值与当前的情况相关性最高。通过应用这些价值,董事会得出结论:不需要重新评估导致 Vistaprint SCO 专家裁决的异议处理程序。

          此行动不会对组织产生任何直接财务影响,也不会对域名系统的安全、稳定或弹性产生直接影响。这属于组织管理职能,无需征询公众意见。

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