Skip to main content
Resources

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到:

本页面还提供其他语种:

12 – 14 October 2014

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

 

  1. 认可议程:
    1. 批准会议记录
  2. 主要议程:
    1. 北京公报中 GAC 关于第 2 类保护 - 独家注册使用的建议
    2. 未达成任何决议。看似不一致的字符串混淆异议专家裁决
    3. 重审请求 14-37,I-Registry Ltd.
    4. GAC 关于保护红十字会和红新月会的建议 — 新加坡公报
    5. 其他事务

 

ICANN 董事会新 gTLD 项目委员会于 2014 年 10 月 12 日召开的会议将持续到 2014 年 10 月 14 日。会议通过的决议如下:

  1. 认可议程:

    1. 批准会议记录

      第 2014.10.12.NG01 号决议:董事会新 gTLD 项目委员会(下称"NGPC")批准 2014 年 9 月 8 日会议的会议记录。

  2. 主要议程:

    1. 北京公报中 GAC 关于第 2 类保护 - 独家注册使用的建议

      未达成任何决议。

    2. 看似不一致的字符串混淆异议专家裁决

      鉴于董事会治理委员会 (BGC) 于 2013 年 10 月 10 日要求工作人员就字符串混淆异议 (SCO) 为 NGPC 起草一份报告,"阐明在处理此 [重审] 请求中提到的情况时的可选方案,即在处理 Amazon 和 TLDH 两者申请的字符串的类似争议时,根据字符串混淆异议争议解决程序得出的不同结果。"

      鉴于 NGPC 已考虑了可能的方法以解决新 gTLD 项目 SCO 流程产生的看似不一致的专家裁决,包括实施一个新审核机制的可行性

      鉴于 2014 年 2 月 5 日,ICANN 董事会 NGPC 要求 ICANN 总裁兼首席执行官或其指定人员针对审核机制提案的框架原则启动公共评议期,该机制旨在解决看似不一致的字符串混淆异议专家裁决(下称"审核机制提案")。若审核机制提案通过,将仅限用于 .CAR/.CARS 和 .CAM/.COM 的字符串混淆异议专家裁决,并构成对《新 gTLD 申请人指导手册》中规定的异议流程的更改。

      鉴于 NGPC 已认真考虑了 BGC 要求工作人员针对重审请求 13-9、收到的关于审核机制提案的公众意见、提供给 NGPC 供其考虑的其他意见以及《申请人指导手册》规定的流程而起草的报告。

      鉴于根据《申请人指导手册》的规定,ICANN 将保留单独考虑任何新 gTLD 申请的权利,以确定批准该申请是否符合互联网社群的最佳利益。

      鉴于根据董事会于 2012 年 4 月 10 日的授权,NGPC 正在代 ICANN 董事会处理所有与新 gTLD 项目相关的问题。

      兹此发布第 2014.10.12.NG02 号决议:NGPC 已确定以下字符串混淆异议专家裁决不符合新 gTLD 项目和互联网社群的最佳利益:

      供审核的 SCO 专家裁决 字符串 相关 SCO 专家裁决
      VeriSign Inc.(异议人)与 United TLD Holdco Ltd.(申请人) .CAM [PDF, 5.96 MB]
      Commercial Connect LLC(异议人)与 Amazon EU S.à r.l.(申请人) .通販 [PDF, 73 KB]1 Top Level Domain Holdings Limited [PDF, 721 KB](.购物)

      第 2014.10.12.NG03 号决议:NGPC 要求总裁兼首席执行官或其指定人员依照本决议和相关理由,采取一切必要措施建立流程和规程,其中规定国际争议解决中心 (ICDR) 应组建一个三人专家组,负责重新评估提交的材料和专家裁决,即上表"供审核的 SCO 专家裁决"栏中所列的两项异议处理程序,并针对这两项处理程序作出最终专家裁决。在此过程中,NGPC 建议三人专家组同时将上表中所列的"相关 SCO 专家裁决"作为背景材料进行审核。

      第 2014.10.12.NG02 - 2013.10.12.NG03 号决议的理由

      目前 NGPC 正在采取措施解决新 gTLD 项目字符串混淆异议流程产生的看似不一致和不合理的专家裁决。NGPC 当前的行动属于其正常监督新 gTLD 项目的职责的一部分。NGPC 的一项职责是"根据新 gTLD 项目解决当前轮次中关于批准申请和授权 gTLD 的问题。"(参阅 NGPC 章程第 II.D 款)。

      《新 gTLD 申请人指导手册》(下称"《AGB》"或"《指导手册》")确定了四大依据,可能会依此对所申请的字符串提出正式异议。其中一个异议就是字符串混淆异议 (SCO),如果异议人认为所申请的 gTLD 字符串容易与同一轮申请中的现有 TLD 或另一个所申请的 gTLD 字符串相混淆,异议人就可以提出此类异议(在满足申诉条件的情况下)。如得到证实,SCO 会改变初步字符争用集的配置,以便在直接争用中同时考虑异议处理程序中的两个有异议的所申请的 gTLD 字符串(参阅 《AGB》第 4 单元:字符串争用程序)。所有 SCO 处理程序均由国际争议解决中心 (ICDR) 管理,所有此类处理程序中的专家裁决均已发布。

      部分利益相关方对看似不一致或不合理的某些 SCO 专家裁决表示担忧。在过去几年中,NGPC 一直在关注此类担忧,并在数次内部会议中就该问题展开过讨论。董事会治理委员会 (BGC) 于 2013 年 10 月 10 日要求工作人员就字符串混淆异议为 NGPC 起草一份报告,"阐明在处理此请求中提到的情况时的可选方案,即在处理 Amazon 和 TLDH 两者申请的字符串的类似争议时,根据字符串混淆异议争议解决程序得出的不同结果。"(参阅 http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-amazon-10oct13-en.pdf [PDF, 131 KB])。

      根据 BGC 在考虑重审请求 13-9 和 13-10 之后提出的请求,以及社群对看似不一致的 SCO 专家裁决表达的担忧,NGPC 考虑了其方案,包括实施一个《申请人指导手册》中未考虑但可在有限情况下使用的审核机制。

      2014 年 2 月 5 日,NGPC 要求 ICANN 总裁兼首席执行官针对审核机制提案的框架原则启动公共评议期,该机制旨在解决看似不一致的字符串混淆异议专家裁决。起草并公布以征询公众意见的审核机制提案仅限用于 .CAR/.CARS 和 .CAM/.COM 的 SCO 专家裁决。审核机制提案的公共评议期已于 2014 年 4 月 3 日结束,意见摘要 [PDF, 165 KB] 也已公布。

      目前,NGPC 正着手解决某些看似不一致或不合理的 SCO 专家裁决,方法是将问题发回给 ICDR 以供三人专家组对某些专家裁决进行评估。NGPC 已认定这些专家裁决不符合新 gTLD 项目和互联网社群的最佳利益。ICDR 将收到补充规则,以便为审核确定的专家裁决提供指导,其中包括以下内容:

      • 审核专家组将由 ICDR 任命的三名成员组成(下称"审核专家组")。

      • 审核专家组负责审核的唯一问题应该是这些决议中确定的 SCO 专家裁决。

      • 供审核的记录应仅限于形成原始专家裁决的处理程序的笔录(如有)、专家报告、在原始处理程序中获准作为证据的文件证据,或其他在原始处理程序中呈交的与审核相关的证据。不能提交任何其他文件、概要或其他证据以供考虑,除非在审核中建议审核专家组考虑上表中确定的"相关 SCO 专家裁决"。

      • 审核专家组应使用的审核标准为:原始专家组对潜在 SCO 的合理决策是否是根据《申请人指导手册》以及 ICDR 针对 ICANN 新 gTLD 项目的补充程序的规定通过适当应用审核标准而达成的。

      • ICANN 将承担审核专家组执行审核的适用费用。

      • 审核结果可能是:(1)审核标准以及所提及的确定的相关专家裁决支持原始专家裁决,将维持原状;(2)审核标准以及所提及的确定的相关专家裁决无法合理地支持原始专家裁决,将被推翻。审核专家组将提交一个书面决定,其中包括对其决定的解释和理由。

      在对该问题进行的长达数月的审议中,以下也是 NGPC 认为至关重要的因素:

      1. NGPC 注意到《指导手册》是由社群按照多利益相关方流程在几年时间内制定的。NGPC 考虑了现在是否适合更改《指导手册》,实施一个审核机制,以处理某些看似不一致的专家裁决。2013 年 4 月 18 日,ICANN 发布了审核机制提案,以征询公众意见。NGPC 认真考虑了所收到的公众意见。NGPC 注意到在公共评议期内提交的意见大致可分为以下几个类别和主题,每一个类别和主题都在公众意见摘要中有更为详细的讨论:

        1. 不采纳审核机制提案。

        2. 采纳审核机制提案。

        3. 采纳扩大范围的审核机制。

        4. 不采纳审核机制提案或扩大范围。

        5. 采纳某些审核形式,但不一定要采纳为征询公众意见而发布的内容。

        6. 如果采纳任何审核机制,建议修改审核机制提案的框架原则。

        各利益相关方提出的意见都强调了在处理对看似不一致的专家裁决的顾虑与《指导手册》规定的流程(数年来,这些流程一直是多轮公众意见讨论的主题)之间的平衡关系时存在的难度和紧迫度。

        正如许多公众意见所强调的,到现在才在流程中采纳审核机制可能是不公平的,因为申请人当时在接受《指导手册》中的流程时,其中并不包括该审核机制,而申请人也依赖于这些流程。NGPC 在权衡之后承认,审核机制不适合当前轮次的新 gTLD 项目,建议为后续轮次的新 gTLD 项目制定相关规则和流程(通过多利益相关方流程制定),从而确定是否有必要针对专家裁决制定一个正式的审核流程。

      2. NGPC 考虑了其在正常监督新 gTLD 项目时的职责与目的。NGPC 在正常监督新 gTLD 项目方面的一项职责是"根据新 gTLD 项目解决当前轮次中关于批准申请和授权 gTLD 的问题。"(参阅 NGPC 章程第 II.D 款)。此外,《申请人指导手册》(第 5.1 款)中还规定:

        ICANN 董事会对新 gTLD 项目负有最终责任。董事会有权自行权衡某一新 gTLD 的申请,以确定批准该申请是否符合互联网社群的最佳利益。特殊情况下,董事会也可以单独考虑某一 gTLD 的申请。例如,在 GAC 对新 gTLD 提出建议后,董事会可以单独考虑该 gTLD 申请,或者在使用 ICANN 问责机制后,董事会也可以这样做。

        除了在《指导手册》中保留董事会在特殊情况下单独考虑 gTLD 申请的权利以外,在 NGPC 的《章程》中针对"申请批准"和"gTLD 授权"部分,还授予 NGPC 自由解决看似不一致和不合理的字符串混淆异议专家裁决的权利。NGPC 考虑到确定的 SCO 专家裁决存在使 NGPC 的行动得到保障的特殊情况,因为每一项专家裁决都超出了被认为合理的普通标准范围。虽然部分社群成员可能觉得其他专家裁决不一致和或不合理,但 NGPC 认为只有确定的 SCO 专家裁决适合开展进一步审核。但是,NGPC 也注意到,针对 .CAR/.CARS 的字符串混淆异议专家裁决不符合新 gTLD 项目和互联网社群的最佳利益。尽管如此,由于 .CAR/.CARS 字符争用集中的相关方最近解决了他们的争用申请,因此 NGPC 并没有将这些 SCO 专家裁决发回给 ICDR,供其重新评估以作出最终专家裁决。

      3. NGPC 还考虑了某些看似不一致的专家裁决是否合理,特别是为什么要将确定的专家裁决发回给 ICDR,而其他专家裁决则不用。NGPC 注意到虽然从表面看来,有些专家裁决似乎不一致,包括其他 SCO 专家裁决以及涉及有限公众利益和社群异议流程的专家裁决,但从程序和实质上看,这些看似有差异的专家裁决却有合理解释。

        首先,从程序上讲,各个专家组一般会根据相关方针对该特定异议向其提交的材料对专家裁决作出判定,且异议方必须承担举证的责任。两个专家组在处理相同问题时,根据所收到材料的效力,可能(适当时应该)会达成不同的决定。

        其次,从实质上讲,社群所强调的被称为是"不一致"或"不合理"的某些专家裁决,在特定异议上会产生微妙的差异。这些微妙的差异不能仅仅因为争议中的某一方反对最终结果就被忽略。再者,指导专家组工作的标准具有一定的主观性,因此独立专家组无法每次都得出相同的结论。然而,对于确定的专家裁决,虽然将之前关于为什么会存在合理"差异"的所有理由都考虑在内,但对看似差异的合理解释仍不够明显。允许这些专家裁决成立又似乎不符合互联网社群的最佳利益。

      4. 根据某些评论者的建议,NGPC 考虑了是否适合扩大审核机制提案的范围,将其他专家裁决包括在内,如社群和有限公众异议得出的一些裁决,以及其他字符串混淆异议专家裁决和相同字符串可能存在的单复数形式的裁决。NGPC 认为要实现可预测性和公平性的目标,在社群日后关于后续轮次的新 gTLD 项目的讨论中建立更广泛的审核机制可能更为合适。申请人已经根据许多专家裁决采取了行动,包括签署《注册局协议》、向授权过渡、撤销申请和请求退款。允许现在撤销上述行动,不仅会推迟对所有申请的考虑,还会对已经按照《申请人指导手册》开展行动的申请人造成不公平。

        此外还应注意的是:作为对政府咨询委员会 (GAC) 所提意见的回应,NGPC 之前还考虑过用户混淆是否有可能是允许相同字符串同时存在单复数形式所造成的。2013 年 6 月 25 日,NGPC 通过了一项决议,即"在解决因允许相同字符串同时存在单复数形式而可能造成的用户混淆方面,无需对《申请人指导手册》中的现有机制做出任何更改"。 http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d。NGPC 还注意到由于相同字符串同时存在单复数形式的议题与后续轮次的新 gTLD 项目相关联,因此可能会成为社群日后讨论的主题。

      5. NGPC 考虑了社群就该问题的致函以及社群在 ICANN 会议上表达的意见。在 ICANN 会议和信函中提出的担忧之处已经纳入对该问题的审议范围之内。

      在上文讨论的 NGPC 对问题的审核完成之前,NGPC 一直推迟考虑 BGC 关于重审请求 13-9 和 13-10 的建议。既然如上所述,NGPC 已采取行动,其将尽快重新开始考虑 BGC 关于重审请求 13-9 和 13-10 的建议。

      通过该决议将会对 ICANN 产生直接的财务影响,因为某些处理程序将发回给 ICDR,以供三人专家组重新审核。批准此项决议不会产生任何与域名系统相关的安全、稳定或弹性问题。

      采取该行动属于组织管理职能,已征询公众意见。有关公众意见的总结,请参阅此处:(https://www.icann.org/en/system/files/files/report-comments-sco-framework-principles-24apr14-en.pdf [PDF, 165 KB])。

    3. 重审请求 14-37,I-Registry Ltd.

      鉴于 iRegistry Ltd.(下称"请求方")提出了重审请求 14-37,要求新 gTLD 项目委员会(下称"NGPC")推翻第 2014.07.30.NG01 - 2014.07.30.NG04 号决议(下称"决议")或"至少修订"该决议,并在请求方提出的问题"得到解决"之后再对如何解决"暂时搁置"的域名冲突作出决定。

      鉴于 BGC 考虑了重审请求 14-37 中提出的问题。

      鉴于 BGC 以请求方未能提供正当的重审依据为由,建议否决该请求,且 NGPC 同意这一建议。

      兹此发布第 2014.10.12.NG04 号决议:NGPC 采纳 BGC 关于重审请求 14-37 的建议,详情请访问 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB] 。

      第 2014.10.12.NG04 号决议的理由

      1. 摘要

        iRegistry Ltd.(下称"请求方")是一家域名注册局,其反对 NGPC 采纳《域名冲突管理框架》(下称"《框架》")。

        在对域名冲突问题展开数次独立研究之后,ICANN 启动了一个从 2014 年 2 月 26 日开始至 2014 年 4 月 21 日结束的公共评议期,在此期间社群就域名冲突问题的可能解决方案提供了反馈,包括实施一个可管理和缓解冲突的框架。在 ICANN 收到的 28 条意见中,没有一条来自该请求方。2

        在考虑收到的公众意见、为分析该问题而开展的详细研究以及相关 ICANN 咨询委员会的建议之后,NGPC 于 2014 年 7 月 30 日批准了第 2014.07.30.NG01 - 2014.07.30.NG04 号决议(下称"决议")3,并采纳了《框架》。《框架》列出了注册局必须遵循的规程,以防止域名冲突损害互联网的安全性或稳定性。

        请求方立即提出请求(请求 14-37),辩称 NGPC 未能让公众充分参与采纳《框架》的决定,并声称《框架》将导致注册人之间产生混淆,引起注册量下降,从而在财务方面对请求方产生不利影响。董事会治理委员会 (BGC) 在对请求 14-37 进行考虑后认为:(i) 没有证据表明 NGPC 在通过决议的过程中所采取的行动需要进行重审;(ii) 请求方没有证明 NGPC 在通过决议时未考虑任何实质性信息,也没有证明 NGPC 在通过决议时所依据的实质性信息存在虚假或错误;以及 (iii) 请求方并未证明其在实质上受到决议的不利影响。因此,BGC 建议否决重审请求 14-37(BGC 建议的完整内容已通过引用的方式纳入,请参见本理由中的阐述)。NGPC 表示认同。

      2. 相关背景事实摘要

        为实现 ICANN 以"保持并提高互联网运营的稳定性、可靠性、安全性和全球互操作性"(《章程》第 1 条第 2.1. 款)为目标的核心价值,ICANN 的安全与稳定咨询委员会(下称"SSAC")发布了 SAC057:SSAC 关于内部域名证书的咨询报告(2013 年 3 月 15 日)。4 报告发现了一种认证机构(下称"CA")的做法,如果被广泛利用,可能会给安全互联网通信的隐私和完整性带来风险。SSAC 建议 ICANN 立即采取措施以缓解风险。SAC057 中发现的问题属于比较普遍的域名冲突问题类别。因此,2013 年 5 月 18 日,ICANN 董事会通过了一项决议,委托进行一项研究,作为对 SSAC 在报告 SAC057 中所提建议的回应。5

        2013 年 8 月 5 日,ICANN 公布了研究结果,说明了新的公共 gTLD 标签与现有供私人使用的相同字符串之间存在冲突的可能性及其潜在后果,该项研究是由 Interisle Consulting Group 开展的。6

        2013 年 10 月 7 日,ICANN 发布了《新 gTLD 冲突事件管理计划》(下称《计划》),该计划允许使用替代路径进行授权。7 在采纳该计划的决议中,NGPC 建议 ICANN 董事会"要求 ICANN 总裁兼首席执行官就管理与新 TLD 授权相关的域名冲突风险制订一项长期计划,并与社群一同就保留和衡量根服务器数据制订一项长期计划"。8

        2013 年 11 月,ICANN 授权 JAS Global Advisors LLC(下称"JAS")作为制定框架的带头人,并与社群保持合作。9

        2014 年 2 月 26 日至 2014 年 4 月 21 日期间,ICANN 启动了一个公共评议期,在此期间社群就域名冲突问题的可能解决方案提供了反馈,包括实施一个可管理和缓解域名冲突的框架;在 ICANN 收到的 28 条意见中,没有一条来自该请求方。10 请求方未参加该公众意见论坛。在收集完公众意见后,JAS 发布了其关于缓解 DNS 域名空间冲突风险的第一阶段报告的最终版。11

        2014 年 6 月 6 日,SSAC 发布了 SAC066:SSAC 关于缓解 DNS 域名空间冲突风险 JAS 第一阶段报告的意见,SSAC 在该意见书中就 JAS 研究和域名冲突框架中描述的框架向董事会提出了意见和建议。12

        2014 年 7 月 27 日,请求方向 ICANN 致函:(i) 请求 ICANN "全面评估"用于解决域名冲突问题的提案,并 (ii) 提供了五条如何解决该问题的具体提案。(请求,示例D。) ICANN 确认已收到请求方于 2014 年 7 月 29 日发出的信函。(请求,示例E。)

        2014 年 7 月 30 日,NGPC 批准了第 2014.07.30.NG01 - 2014.07.30.NG04 号决议(下称"决议"),该决议采纳了《框架》。《框架》列出了注册局必须遵循的规程,防止域名冲突损害互联网的安全性或稳定性,并要求"总裁兼首席执行官或其指定人员采取必要措施落实"该《框架》。13

        2014 年 8 月 4 日,ICANN 全球域名分部向各新 gTLD 注册局运营商发布了域名冲突事件评估(下称"评估"),其中明确了注册局必须根据《框架》采取哪些措施才能避免出现域名冲突问题。14 同日,请求方通过电子邮件收到了评估。(请求,示例A。)

        2014 年 8 月 12 日,ICANN 召开了一次网络研讨会,专门向注册局运营商简要介绍了《框架》内容。15

        2014 年 8 月 13 日,请求方立即提出请求,希望重审 NGPC 的决议。

        虽然《框架》中并未说明如何处理域名冲突问题对某一类域名产生的影响,但是 ICANN 正在就此主题收集公众意见。具体来说,ICANN 就此特定问题开放了公众意见论坛,开放时间为 2014 年 8 月 25 日至 2014 年 10 月 7 日。16

        2014 年 9 月 4 日,董事会治理委员会(下称"BGC")发布了关于重审请求 14-37 的建议。17 2014 年 9 月 11 日,请求方提交了一份关于重审请求 14-37 的说明文件,18其中就决议以及《框架》的采纳如何从实质上对请求方造成影响的事宜作出了详尽的声明。

      3. 问题

        要重审的问题为 NGPC:

        1. 在批准决议(请求第 8 款第 11 页)时,是否并未考虑社群所提供的实质性意见;以及
        2. 是否不恰当地低估了决议会带来的潜在不利影响。(同上第 8 款第7-8 页)。
      4. 评估重审请求的适用标准

        根据《ICANN 章程》的规定,BGC 应负责评估董事会(或 NGPC)收到的关于重审请求的建议,并在董事会(或 NGPC)就请求采取的行动受到质疑时为其提供相关建议 请参阅 AICANN 章程》第 IV 条第 2 款。在此案例中,NGPC 被赋予了董事会的权利,审核和全面考虑了 BGC 关于请求 14-37 的建议,并且认定其分析合理。19

      5. 分析和理由

        请求方未能证明董事会在通过决议时未考虑任何实质性信息,或所依据的实质性信息存在虚假或错误,因此重审是不恰当的。

        1. 即决驳回请求。

          BGC 认为请求方理由不充分,因为请求方"在受争议的行动上已获得通知并有机会参加公共评议期,但却未参加",NGPC 同意这一看法。(《章程》第 IV 条第 2.9 款。)具体而言,如果"请求方在受争议的行动上已获得通知并有机会参加公共评议期,但却未参加",《ICANN 章程》允许 BGC 即决驳回重审请求"。(《章程》第 IV 条第 2.9 款。)

          2014 年 2 月 26 日至 2014 年 4 月 21 日期间,ICANN 在其网站上启动了公共评议期,在此期间社群就域名冲突问题的可能解决方案(包括框架)提供了反馈。20 论坛共收到 28 条意见,但该请求方并未参加该公众意见论坛,亦未就其为何作出不参加该论坛的决定提供任何理由、原因或解释。请求方声称,其与 ICANN 在域名冲突问题上的唯一一次沟通是其于 2014 年 7 月 27 日向后者发送的一份信函,而信函发送之时,公共评议期早已结束。21 鉴于该公共评议期无可争辩地与决议相关,根据请求方未参加的事实,即决驳回请求。虽然如此,为了确保完整性,NGPC 还是会考虑请求益处。

        2. NGPC 考虑了所有实质性信息。

          BGC 认为请求方未能证明 NGPC 没有考虑实质性相关信息,NGPC 同意这一看法。

          要为重审董事会的行动提供依据,请求方必须证明董事会(或该案例中的 NGPC)在通过决议时未考虑任何实质性信息,或所依据的实质性信息存在虚假或错误。(《章程》第 IV 条第 2.2 款。)请求方并未辩称 NGPC 所依据的是虚假或错误的实质性信息,但却从两方面提出 NGPC 未考虑实质性信息。第一,请求方声称 NGPC 在通过决议之前未充分咨询公众意见。第二,请求方声称 NGPC 未考虑该决议将对注册局和互联网用户造成的实质性不利影响。但这两个辩论点都经不起仔细考究,均不得作为重审的依据。

          1. NGPC 考虑了在漫长的公共评议期中收集到的公众意见。

            请求方声称 NGPC"未考虑社群提供的实质性意见"。(请求第 8 款第 11 页。)与请求方的声明相反,NGPC 恰恰考虑了在"公众意见论坛"上收集到的反馈,22 该论坛的开放时间为 2014 年 2 月 26 日至 2014 年 4 月 21 日。请求方没有就其为何不参加该论坛给出解释。如果请求方当时参加了该论坛,其提交的意见就可以与其他利益相关方和公共机构成员(包括其他注册局)提交的 28 条详细意见一起受到考虑。23 很明显,针对该事件启动的公共评议期实际上远远长于所需要的时间。一般情况下,公共评议期为 21 天,如果在此期间收到意见,随后将启动同样为时 21 天的回复期。24 此次公共评议期持续了 33 天之久,随后也启动了 21 天的回复期。此外,ICANN 还在其于 2014 年 6 月 23 日召开的伦敦会议期间就域名冲突问题举行了一次全面的公共会议,再次向公众提供了一次提意见和参加的机会,但请求方仍选择不参加。25 因此,请求方没有合理理由声称 NGPC 在通过决议之前未考虑公众意见。

            总之,请求方没有充分理由证明 NGPC 在通过决议时未考虑以公众意见形式提交的实质性信息,因此重审没有适当依据。(《章程》第 IV 条第 2.2 款。)

          2. NGPC 考虑了与决议相关的所有实质性信息。

            请求方请求对决议进行重审,因为其声称 NGPC"没有适当地评估该决定可能造成的影响"。(请求第 8 款第 12 页。)请求方作出该判定的主要依据是决议的"理由"章节中未明确解决其在 2014 年 7 月 27 日发送的信函中所述之问题。这一论据不能构成重审的依据,原因有两点:

            首先,决议 的确 考虑了请求方于 2014 年 7 月 27 日发送的信函所述之信息。2014 年 7 月 27 日的信函中提出了五个请求,所有请求不是关于"RPM 规则",就是请求方认为应为所有 gTLD 应用一组通用规则。(请求第 8 款第 10 页和示例D。) 尽管请求方这样认为,但事实并非如此,其于 2014 年 7 月 27 日发送的信函中所述之所有问题,其他利益相关方在公共评议期均已向 NGPC 提出,NGPC 也解决了这些问题。决议确认 NGPC 考虑了以下公众意见:(i) 对"域名冲突拦截清单与知识产权保护机制之间协调问题"的担忧26;(ii) 提到"域名冲突问题如何造成不公平的竞争环境"的问题;以及 (iii) 讨论以有别于对待传统运营商的方式对待新 gTLD 运营商的利与弊。27 此外 ICANN 已确认需要更多公众意见才能作出如何处理 RPM 问题的决定。实际上,在 2014 年 8 月 25 日至 2014 年 10 月 7 日之间,ICANN 正在收集应如何处理"关于为发布二级域名拦截清单创建适当的权利保护机制"问题的意见。28 换句话说,不论是否具体考虑过请求方于 2014 年 7 月 27 日发送的信函中所述之信息,NGPC 都没有遗漏任何相关问题的实质性信息。

            其次,请求方不同意《框架》中的内容并不能构成重审的适当依据。NGPC 考虑了为讨论域名冲突问题而开展的独立而详尽的研究,包括 JAS 和 Interisle Consulting Group 分别开展的研究。29 此外,NGPC 在通过决议之前还考虑了 SSAC 提供的建议。SSAC 的职能是"负责针对互联网名称和地址分配系统的安全性与整合性向 ICANN 社群和董事会提供有关问题的建议"。(《章程》第 XI 条第 2.a. 款。)总之,NGPC 考虑了公众意见、独立分析报告以及相关 ICANN 咨询委员会给出的建议。虽然请求方投诉称 NGPC"未提及信函"(该信函是请求方在公共评议期结束数月之后才发送的),并且在批准《框架》之前"没有适当解决决定会造成的影响",但这些指控并不足以作为断定 NGPC 未考虑任何实质性信息的依据。因此不予批准重审。

            最后一点,请求方还声称因"没有证据表明 GAC30 曾有机会就 JAS 报告或 SSAC 建议提供反馈"而应批准重审。(请求第 7 款第 7 页) GAC 可以"就政府关注的 ICANN 事务(特别是可能需要 ICANN 政策与各种法律及国际协议进行协调的事务或者可能影响公共政策问题的事务)提出相关建议。"(《章程》第 XI 条第 2.1 款。)GAC 未就 ICANN 应如何解决域名冲突问题提出任何正式建议并不代表 NGPC 没有考虑过任何实质性信息。如果 GAC 曾提供此类建议,ICANN 董事会将会根据《ICANN 章程》的规定考虑这些建议。(《ICANN 章程》第 XI 条第 2.1.i 和 2.1.j 款。)此外,2013 年 7 月,GAC 德班公报的确曾建议董事会"尽快考虑 SSAC 报告中关于无点域 (SAC053) 和互联网域名证书 (SAC057) 的建议",后者涉及域名冲突问题。31 董事会的确考虑了 SSAC 的建议,然后才通过了《框架》。

            同样地,请求方无法证明 NGPC 在通过决议时未考虑实质性信息,因此重审是不恰当的。(《章程》第 IV 条第 2.2 款。)

        3. 声称的混淆因素不能构成重审依据。

          BGC 认为,请求方未能证明 NGPC 没有考虑关于让公众了解《框架》的重要性的实质性信息,NGPC 同意这一看法。

          请求方投诉称 NGPC 没有考虑其认为存在的事实,即"绝大多数"注册人没有意识到域名冲突问题,因此才会"普遍对域名的可用性产生混淆"。(请求第 7 款第 6 页。)然而,很显然 NGPC 恰恰考虑了关于让公众了解《框架》的重要性的信息。决议还专门制定了一项针对"信息材料"的完整条款(第 B.6 款),并要求 ICANN"根据需要制作信息材料....[并]着手将此类信息提供给受域名冲突影响的相关方"。32 虽然《框架》是最近刚通过的,但 ICANN 已经发布并提供了一系列广泛的信息材料,包括面向注册局运营商的网络研讨会、供 IT 专业人员使用的手册和视频,以及针对《框架》的"常见问题"页面。33 此外,ICANN 还投入专项资源,用于确保关于评估或《框架》问题得到适当而准确地解答。换句话说,ICANN 不但考虑了决议可能造成的混淆,还积极采取重要措施,确保受影响的相关方能理解《框架》以及其所需的措施。34 很明显 NGPC 的确考虑了此类信息,并通过上述教育资源采取了相关行动,因此没有证据证明 NGPC 没有考虑关于公共外展活动的信息,不予批准重审。

        4. 请求方未能证明其受到决议的实质性影响。

          BGC 认为,请求方未能证明其受到决议的实质性不利影响,NGPC 同意这一看法。

          因缺乏证据证明请求方受到决议的实质性不利影响,因此重审是不恰当的。(《章程》第 IV 条第 2.1-2.2 款。)请求方在此声称其受到决议的实质性不利影响的原因有两点。(请求第 6 款第 4-5 页。)首先,请求方辩称《框架》没有就如何防止受到域名冲突的损害提供明确指示。(同上第 5 页。)其次,请求方辩称《框架》引起的所谓的混淆会致其蒙受"注册率降低"的损失,因为请求方推测注册商"不会为域名冲突清单中的域名提供注册"。(同上.) 。)然而,上述担忧均不属实,且目前也仅为推测。 35 再次强调,只有"受到 ICANN 行动不利影响"的人员才可以提出重审请求。(《章程》第 IV 条第 2.2 款)(重点标示)。由于该请求方认定的唯一损害就目前来看仅为推测和猜测,所以请求重审的理由不成立。36

          因此,请求方未能证明其 受到 决议的实质性影响,根据该独立论据,将不批准重审通过的决议。

      6. 决定

        NGPC 有机会对请求方提交或以请求方名义提交的所有材料或者其他与请求 14-37 相关的所有材料进行考量。在考虑了收到的所有相关信息之后,NGPC 审核并通过了 BGC 关于请求 14-37 的建议 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB],这份建议附于 NGPC 就此事项提交的材料的参考材料中,应视为决议理由的一部分。

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

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

    4. GAC 关于保护红十字会和红新月会的建议 — 新加坡公报

      鉴于 GAC 在 ICANN 第 49 届新加坡会议期间举行了会议,并于 2014 年 3 月 27 日发布了 公报 [PDF., 449 KB] (下称"新加坡公报")。

      鉴于在新加坡公报中,GAC 阐述了其曾向 ICANN 董事会提出的建议,该建议指出应永久保护国际红十字会和红新月会运动所用术语不会出现未经授权使用的情况,并建议该保护范围还应包括"189 个国家红十字会和红新月会所用的术语,无论这些术语采用英语还是相应国家的源语言",以及"以全部 6 种联合国官方语言表述的红十字国际委员会及红十字会与红新月会国际联合会的全名"。以上 GAC 建议在 GAC 建议注册中编号为 2014-03-27-RCRC

      鉴于 GNSO 已就红十字会和红新月会的名称向董事会提出了政策建议(该事项也是 GAC 新加坡公报的主题)。GNSO 政策建议中的保护范围与 GAC 的建议有所不同,GAC、GNSO、董事会和 ICANN 社群将继续积极解决存在的差异。

      鉴于董事会于 2012 年 4 月 10 日授权 NGPC 代其处理与新 gTLD 项目相关的所有问题,该委员会有责任考虑 GAC 建议。

      兹此发布第 2014.10.12.NG05 号决议:要求总裁兼首席执行官或其指定人员根据 GAC 建议注册中编号为 2014-03-27-RCRC 的建议,为红十字国际委员会、红十字会与红新月会国际联合会、189 个国家红十字会和红新月会的名称提供临时保护,同时,GAC、GNSO、董事会和 ICANN 社群将继续积极解决 GAC 建议与 GNSO 政策建议在 RCRC 名称保护范围上存在的差异。

      第 2014.10.12.NG05 号决议的理由

      NGPC 正在采取行动为新加坡公报 GAC 建议中提出的红十字会/红新月会 (RCRC) 的名称提供临时保护,同时也积极参与 GAC、GNSO、董事会和 ICANN 社群为积极解决 GAC 建议与 GNSO 政策建议在 RCRC 名称保护范围上存在的差异所展开的重要讨论。

      根据《ICANN 章程》第 XI 条第 2.1 款 ,GAC 可以"直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议"。GAC 在 2014 年 3 月 27 日发布的新加坡公报(下称"新加坡公报")中就新 gTLD 项目向董事会提出了建议。《ICANN 章程》要求董事会在政策制定和采纳中考虑 GAC 对公共政策问题的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。然后,董事会和 GAC 需要本着真诚合作的态度找到一个双方都可以接受的解决方案。如果找不到这样的解决方案,董事会必须在其最终决定中解释不采纳 GAC 建议的原因。

      在新加坡公报中,GAC 阐述了其曾向 ICANN 董事会提出的建议,该建议指出应永久保护国际红十字会和红新月会运动所用术语不会出现未经授权使用的情况,并建议该保护范围还应包括"189 个国家红十字会和红新月会所用的术语,无论这些术语采用英语还是相应国家的源语言",以及"以全部 6 种联合国官方语言表述的红十字国际委员会及红十字会与红新月会国际联合会的全名"。

      GNSO 还向 ICANN 董事会就相同的 RCRC 名称提供了政策建议(该事项也是新加坡公报中 GAC 建议的主题)。与 GAC 建议不同,GNSO 的政策建议并未建议为这组 RCRC 名称提供永久保护。而是建议通过将这些名称录入到 TMCH,进行为期 90 天的声明通知,从而为这些名称提供保护。

      2014 年 4 月 30 日,ICANN 董事会 采纳了 GNSO 理事会在 IGO-INGO 保护上与 GAC 建议不同的政策建议,并请求更多时间用以考虑与 GAC 在同一主题上的建议不同的其他政策建议。董事会致力于推动相关方之间的讨论,以调解政策建议与 GAC 建议在该主题上存在的任何其他差异,并已任命 NGPC 为该流程提供帮助。NGPC 目前所采取的措施是向新加坡公报 GAC 建议中提出的 RCRC 名称提供临时保护,同时积极参与 GAC、GNSO、董事会和 ICANN 社群为积极解决 GAC 建议与 GNSO 政策建议在 RCRC 名称保护范围上存在的差异所展开的重要讨论。

      NGPC 的行动将对社群产生积极影响,因为它在为 RCRC 名称提供临时保护的同时也在持续展开讨论。NGPC 在审议过程中审核了以下重要材料和文件:

      通过此项决议不会产生任何可预见的财务影响。批准此项决议不会产生任何与 DNS 相关的安全、稳定或弹性问题。该行动不属于 ICANN 支持组织内部定义的政策流程,也不属于需要或不需要征询公众意见的 ICANN 组织管理职能决策。关于为 RCRC 名称提供保护的后续行动可能会视公众意见而定。

    5. 其他事务

      未达成任何决议。

Published on 14 October 2014


1 "网购"的日语翻译

2 有关 《公众意见报告》, 请访问 https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

3 有关 决议" 请访问 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

4 有关 https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF,1.13 MB].

5 有关 https://features.icann.org/ssac-advisory-internal-name-certificates.

6 有关 "解决域名冲突的后果", 请访问 https://www.icann.org/news/announcement-3-2013-08-05-en.

7 有关 《新 gTLD 冲突事件管理计划》常见问题解答,请访问 https://www.icann.org/news/announcement-2013-12-03-en.

8 有关 https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-10-07-en#1.a.

9 有关 https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

10 有关 《公众意见报告》,请访问 https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

11 有关《JAS 报告》,请访问 https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf [PDF, 391 KB].

12 有关 https://www.icann.org/en/system/files/files/sac-066-en.pdf [PDF, 305 KB].

13 有关 "决议"内容, 请访问 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

14 有关 "域名冲突事件评估", 请访问 http://newgtlds.icann.org/sites/default/files/agreements/name-collision-assessment-04aug14-en.pdf [PDF, 91 KB].

15 有关 https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

16 有关 《域名冲突缓解框架》中权利保护机制的实施, 请访问 https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en.

17 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB]

18 https://www.icann.org/en/system/files/files/clarification-i-registry-11sep14-en.pdf [PDF, 59 KB]

19 制定重审流程,为 BGC 审核董事会/NGPC 收到的建议并在需要时向董事会/NGPC 提供建议供其审批提供依据,这一做法可有效改善 ICANN 的透明度和问责制。它为社群提供了一个途径,确保工作人员和董事会的行为符合 ICANN 政策、《ICANN 章程》以及《企业设立章程》。

20 有关 《公众意见报告》,请访问 https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

21 请求方声称其"早在"NGPC 会议召开前就向 NGPC 发送了信函,但是鉴于信函发送日期与 2014 年 7 月 30 日 NGPC 会议召开之间仅有三天间隔时间,该声明不成立。(有关 请求第 8 款第 9 页。)

22 有关 "决议"内容, 请访问 https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

23 有关 《公众意见报告》, 请访问 https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

24 有关 https://www.icann.org/resources/pages/how-2014-03-17-en

25 有关 ICANN 第 50 届伦敦会议的域名冲突演示文稿, 请访问 https://london50.icann.org/en/schedule/mon-name-collision/presentation-name-collision-23jun14-en.

26 有关 "决议"内容,请访问 https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

27 有关 《公众意见报告》第 11 页,请访问 https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

28 有关 《域名冲突缓解框架》中权利保护机制的实施, 请访问 https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en

29 有关 "决议"内容, 请访问 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

30 政府咨询委员会。

31 有关 在 ICANN 第 47 届会议上发布的 GAC 公报,请访问 https://www.icann.org/news/announcement-2013-07-18-en有关 SAC057,请访问 https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF, 1.13 KB].

32 有关 "决议"内容, 请访问 https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

33 有关 域名冲突资源和信息,请访问 https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

34 ICANN 还通过 LinkedIn 和各种媒体传播渠道以及启动 Google Adwords 关键词广告推广参与了许多重大的外展活动。

35 实际上,《框架》现已允许在 DNS 中激活以前不允许激活的域名。因此,《框架》很有可能会引起注册量增加。

36 当 BGC 发布其建议后,请求方随即于 2014 年 9 月 11 日提交了一份针对重审请求 14-37 的说明文件,据称该文件提供了关于请求方受到决议的实质性不利影响的更多详细信息。尽管请求方认为这样,但事实并非如此,请求方对潜在损害的持续辩解仍是推测和猜测。

resolutions-new-gtld-12oct14-zh.pdf  [403 KB]

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