Skip to main content
Resources

批准的决议 | 新 gTLD 计划委员会会议

本页面还提供其他语种:

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

 

  1. 主要议程
    1. 域名冲突管理框架

 

  1. 主要议程

    1. 域名冲突管理框架

      鉴于 2013 年 10 月 7 日 NGPC 要求全球域名部门总裁落实一项旨在妥善管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件的提案(该提案载于"新 gTLD 冲突事件管理计划",简称"冲突事件管理计划"),以便考虑安全与稳定咨询委员会 (SSAC) 及其他专家和利益相关方可能提出的其他建议。

      鉴于冲突事件管理计划需要进行后续研究,以便报告域名冲突管理框架的最新进展。

      鉴于 2014 年 2 月 26 日,ICANN 发布了 NGPC 2013 年 10 月 7 日决议中要求的后续研究报告,该研究报告由 JAS Global Advisors (JAS) 编写,报告的标题为"缓解 DNS 命名空间冲突的风险:有关全球互联网 DNS 命名空间中的命名空间冲突及风险缓解框架的研究第一阶段报告" [PDF, 322 KB] (简称"JAS 研究和域名冲突框架")。JAS 研究和域名冲突框架提出了一系列建议,建议中描述了一个综合框架,该框架可以减少当前和未来的 DNS 命名空间冲突,提醒运营商潜在的 DNS 命名空间相关问题,并在关键系统(如生命安全)受到负面影响时提供应急响应能力。该报告已发布用于征询公众意见。JAS 研究和域名冲突框架针对公众意见进行了修改 [PDF, 392 KB]。

      鉴于 2014 年 6 月 6 日,ICANN 安全与稳定咨询委员会 (SSAC) 公布了 SAC 066:[PDF, 306 KB] SSAC 关于缓解 DNS 命名空间冲突风险 JAS 第一阶段报告的意见,SSAC 在该意见书中就 JAS 研究和域名冲突框架中描述的框架向董事会提出了意见和建议。

      鉴于提交至 NGPC 供其考虑的拟议域名冲突框架考虑了 SSAC 在 SAC066 中提出的建议以及其他专家和利益相关方的建议(包括 JAS 的建议、公众意见和 ICANN 会议期间各个社群的讨论内容)。

      鉴于 NGPC 确认了社群提出的关于需要确保所有域名(此类域名被注册局根据其授权替代路径报告而拦截)遵循新 gTLD 项目确立的权利保护机制的意见。

      鉴于 ICANN 董事会之前采纳了 NGPC 的建议,要求 ICANN 总裁兼首席执行官就管理根域中的域名冲突制定一项长期计划。

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

      兹此发布第 2014.07.30.NG01 号决议:NGPC 采纳了域名冲突管理框架 <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 634 KB],以继续管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件,并要求总裁兼首席执行官或其指定人员采取必要措施落实域名冲突管理框架。在落实框架期间,注册局运营商将接受域名冲突事件评估(参见注册局协议规定6 第 6 节)。除了其他程序外,该评估还将处理从拦截清单中移除二级域名的程序(包括保护权利持有者的措施)。

      第 2014.07.30.NG02 号决议:NGPC 要求总裁兼首席执行官或其指定人员在发布决议后的 90 天内与社群进行商议,以解决针对注册局运营商授权替代路径报告中纳入的域名和商标信息交换中心记录的域名(注册局运营商在优先注册期或声明期保留分配的域名)的适当权利保护机制。

      第 2014.07.30.NG03 号决议:NGPC 要求总裁兼首席执行官或其指定人员向 GNSO 提供信息并与之商榷是否应启动旨在制定一个长期计划来管理 gTLD 域名冲突问题的政策工作。

      第 2014.07.30.NG04 号决议:NGPC 要求总裁兼首席执行官或其指定人员继续就域名冲突管理框架的域名冲突问题向 ccTLD 经理提供简报,并与之分享信息和最佳实践。

      第 2014.07.30.NG01 – 2014.07.30.NG04 号决议的理由

      为什么 NGPC现在要考虑这个问题?

      NGPC 目前采取的行动是之前解决域名冲突问题的各种措施的延续。需要强调的是,2013 年 10 月 7 日 NGPC 采取行动要求全球域名部门总裁落实一项旨在妥善管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件的提案(该提案载于"新 gTLD 冲突事件管理计划",简称"冲突事件管理计划"),以便考虑安全与稳定咨询委员会 (SSAC) 和其他专家和利益相关方可能提出的其他建议。冲突事件管理计划的核心内容包括要求 ICANN 开展另外一项研究,以制定域名冲突管理框架。此框架旨在指定一套冲突事件评估方法和相应的缓解措施(如有),这些措施可能需要 ICANN 或新 gTLD 申请人予以落实。

      为了落实 NGPC 2013 年 10 月 7 日的行动,ICANN 于 2014 年 2 月 24 日发布了 JAS Global Advisors(简称"JAS")编写的研究报告,报告的标题为"缓解 DNS 命名空间冲突的风险:有关全球互联网 DNS 命名空间中的命名空间冲突及风险缓解框架的研究第一阶段报告"(简称"JAS 研究和域名冲突框架")。JAS 研究和域名冲突框架提出了一系列建议,建议中描述了一个综合框架,该框架可以减少当前和未来的 DNS 命名空间冲突,提醒运营商潜在的 DNS 命名空间相关问题,并在关键系统(如生命安全)受到负面影响时提供应急响应能力。此外,SSAC 就 JAS 报告中的拟议域名冲突框架向董事会提出了建议和意见,这些建议与意见载于 SAC 066:SSAC 关于缓解 DNS 命名空间冲突风险 JAS 第一阶段报告的意见 [PDF, 306 KB]。

      此时,NGPC 正在采纳域名冲突管理框架(日期:2014 年 7 月 30 日)<https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 634 KB],这是冲突事件管理计划中要求的框架的最终版本(简称"最终域名冲突框架")。最终域名冲突框架以 JAS 研究和域名冲突框架中的框架为基础而建立,并已根据 SAC066 的建议、公众意见和 ICANN 伦敦会议期间的社群反馈做出进一步改善。采纳并落实最终域名冲突框架有助于 ICANN 继续安全、稳定地推动新 gTLD 的授权流程。

      考虑了哪些提案?

      NGPC 当前采纳的最终域名冲突框架就管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件提出了一项计划。最终域名冲突框架的某些关键要素概述如下:

      对注册局的一般要求:

      • 在 TLD 有效期(自 TLD 授权时间开始计算)的前两年内,必须在 ICANN 报告后的两小时内对域名冲突报告采取行动。
      • 必须实施"控制性中断"作为通知手段,以提醒各方他们可能将来自专用命名空间的查询泄露给了公共 DNS。控制性中断必须为连续中断(即不间断)并持续长达 90 天。一般而言,如果 TLD 在既定截止日期之前获得授权,那么注册局运营商会使用 MX、SRV 和 TXT 和 A 记录对拦截清单中的二级域名实施控制性中断。对于在既定截止日期之后授权的 TLD,注册局运营商会使用通配符方法来实施控制性中断。控制性中断(针对 IPv4)将使用回送地址 (127.0.53.53)

      对 ICANN 的要求:

      • 配合 IETF 的工作,并与其他相关技术社群协同确定 IPv6 的通知机制,该机制提供与 IPv4"回送"保留前缀中所用机制类似的功能。
      • 无限推迟授权 .MAIL,并与技术和安全社群协同确定处理 .MAIL 的最佳方式(例如通过 IETF 流程实现永久保留)。JAS 研究和域名冲突框架认为 .MAIL 使用的"广泛和普遍程度远高于所有其他申请的 TLD",因此该域名的普遍内部使用可能无法逆转。
      • 制作新的外展和信息材料以便提醒潜在的受影响各方与域名冲突有关的情况,新材料应关联至首次外展活动时制定的关于域名冲突的现有信息。

      NGPC 目前的行动还解决了社群提出的问题,即需要确保域名(此类域名被注册局根据其授权替代路径报告而拦截)遵循新 gTLD 项目确立的适当权利保护机制。为了解决此问题,NGPC 要求总裁兼首席执行官或其指定人员在发布决议后的 90 天内与社群进行商议,以解决针对注册局运营商授权替代路径报告中纳入的域名和商标信息交换中心记录的域名(注册局运营商在优先注册期或声明期保留分配的域名)的适当权利保护机制。

      为了跟进一条之前向董事会提出的建议(即要求总裁兼首席执行官制定一个长期计划来管理根域的域名冲突问题),NGPC 目前的行动要求总裁兼首席执行官或其指定人员向 GNSO 提供信息并与之商榷是否应启动旨在制定一个长期计划来管理 gTLD 域名冲突问题的政策工作。NGPC 还采取行动要求总裁兼首席执行官或其指定人员继续就采用域名冲突管理框架方面的域名冲突问题向 ccTLD 经理提供简报,并与之分享信息和最佳实践。

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

      ICANN 启动了一个公众意见征询论坛,邀请各社群对 JAS 研究和域名冲突框架发表意见,论坛开放期为 2014 年 2 月 26 日至 4 月 21 日。此次公共评议期共收集到 28 条意见。公众意见报告总结了各方意见,如需查看全部意见,请访问: https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 230 KB]。

      ICANN 还咨询了 SSAC,且 SSAC 就 JAS 研究和域名冲突框架中拟议的域名冲突框架向董事会提出了意见和建议(通过 SAC066)。另外,ICANN 在 ICANN 伦敦会议期间呈交了拟议的最终域名冲突框架版本。

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

      JAS 研究和域名冲突框架在公共评议期内收到了各方提出的共 28 条意见,其中包括新 gTLD 申请人及其附属机构、非直接附属机构、个人技术专家以及各种 DNS 相关行业组织。社群成员还就域名冲突问题与权利保护机制之间的协调问题向 ICANN 致函。此外,SSAC 在 SAC066 中对域名冲突框架提出了一些疑虑。

      已纳入 SSAC 和 ICANN 社群提出的一些关键主题和疑虑,但不限于以下内容:

      • 关于当前常规使用二级域名 (SLD) 拦截清单和授权替代路径的疑虑。
      • 关于拟议的 120 天"控制性中断"期过长和/或不合理的疑虑 – 一些评论者认为没有数据可以支持需要长达 120 天的控制性中断期,且如果需要这么一个时期,则天数应介于 45 天到 90 天之间。
      • 关于使用"回送"方式而不是"honeypot"方式的疑虑 – SSAC 建议使用 honeypot 方式,因为这种方式不仅可以更好地通知 HTTP 案例,还可以为 IPv4 和 IPv6 提供支持。一些公众意见还认为 honeypot 方式可以更好地通知用户即将发生的问题。但其他评论者认为,除了其他问题之外,honeypot 还可能会将个人身份或敏感信息披露到本地网络外或泄露给潜在的攻击者。
      • 关于控制性中断应为连续型还是间歇型的疑虑 – SSAC 建议,ICANN 应采用滚动的中断期而不是单独的控制性中断期,然后按照正常运营期分段,这样可以允许受影响的最终用户系统在测试期期间继续正常工作,降低产生灾难性业务影响的风险。
      • 关于什么类型的事件会触发应急响应的疑虑 – SSAC 建议 ICANN 应扩大会触发应急响应的情况的范围,例如国家安全、应急准备、重要基础设施、关键经济过程、贸易以及法律和秩序维持。一些公众意见还就"对人类生命造成迫在眉睫的明确威胁"的标准提出质疑,认为这一标准太过宽泛,而其他人则认为某些会对全球经济的商业和金融领域产生重大危险的情况也值得采取应急措施。
      • 关于 .CORP、.HOME 和 .MAIL 处理方式的疑虑 – 一部分公众意见支持 JAS 研究和域名冲突框架中推荐的 .CORP、.HOME 和 .MAIL 处理方式,而其他意见则认为,对此问题的最终决定应延迟到可以执行更全面的技术评估之后再做出,因为 到时可能会制定出一个解决方法,让这些字符串在 DNS 中运行。
      • 要求普遍提高冲突问题的结案效率的意见 – 部分社群成员提出一个颇具普遍性的疑虑:新 gTLD 流程早已提上日程,为何这么晚才开始处理域名冲突问题?ICANN 为何没有及早处理此事?评论者还对时间问题提出了疑虑,要求 ICANN 尽快对事件采取行动,避免进一步延迟。
      • 许多意见表达了对域名冲突拦截清单与知识产权保护机制之间协调问题的疑虑 – 部分提交至 ICANN 的公众意见和信函建议,所有域名(此类域名被注册局根据其授权替代路径计划而拦截)需遵循 gTLD 申请人指导手册中所述的优先注册和商标通知服务、注册局协议、权利保护机制要求 (RPM) 或其他保护权利持有者的类似机制。另外,一些 .BRAND TLD 申请人发现,拦截清单中的很多"品牌"术语是品牌产品和服务的商标,而且像是品牌自身在根域生成的。评论者建议 ICANN 考虑为 .BRAND TLD 申请人增设一个新的流程,以加快这些商标术语的发放速度,便于立即使用。

      NGPC审核了哪些重要材料?

      NGPC 审核了多份材料,包括但不限于以下材料:

      NGPC认为至关重要的因素有哪些?

      在衡量是否应采纳最终域名冲突框架时,NGPC 考虑了许多重要因素。以下是这些因素中 NGPC 认为至关重要的:

      • NGPC 考虑了 SSAC 的建议(包括在 SAC066 中提出的建议)。
      • 如前所述,包括 SSAC 在内的部分评论者对使用"回送"方式而不使用"honeypot"方式提出了疑虑。选择在最终域名冲突框架中使用回送方式时,NGPC 考虑了 SAC 062 和 066 以及 JAS 报告中描述的与 honeypot 方式有关的隐私和法律风险。总体而言,NGPC 指出,使用回送方式提供的通知功能可以更好地向系统通知域名冲突事件,同时还可以尽量减少使用 honeypot 方式的固有问题。NGPC 还指出,虽然 honeypot 方式可以提供 IPv6 解决方案,但是最终域名冲突框架纳入了一项要求,即 ICANN 将配合 IETF 的工作,并与其他相关技术社群协同确定 IPv6 的机制,该机制提供与 IPv4"回送"保留前缀中所用机制类似的功能。
      • NGPC 还注意到关于控制性中断应为连续型还是间歇型的重要意见。尽管 SSAC 建议采用间歇型控制性中断,但其承认控制性中断的每种方式都需要进行权衡,并做出判断。从运营的层面看,间歇型方式会对注册局和 ICANN 实施和确保正常运转造成更大的风险。另一方面,连续型控制性中断提供了更加简单的运作方式,并且更容易发现问题和进行故障排除。它还提供一种更有效的方式,可指示受影响方的网络配置是否需要变更。此外,从理论上看,当控制性中断处于"关闭"周期时,间歇型控制性中断方式可以让受影响方得到暂时缓解。需要注意的是,如果已经有一种机制(域名冲突报告)可以让受影响方暂时减轻域名冲突损害,那么需要时可以使间歇型方式成为不必要的负担。
      • NGPC 考虑了社群提出的疑虑,即需要确保域名(此类域名被注册局根据其授权替代路径报告而拦截)遵循新 gTLD 项目确立的权利保护机制。如前所述,为了解决此问题,NGPC 要求总裁兼首席执行官或其指定人员在发布决议后的 90 天内与社群进行商议,以解决针对注册局运营商授权替代路径报告中纳入的域名和商标信息交换中心记录的域名(注册局运营商在优先注册期或声明期保留分配的域名)的适当权利保护机制。
      • NGPC 考虑了关于哪种类型的事件会触发应急响应的建议。目前采纳的最终域名冲突框架会限制域名冲突报告的应急响应情况,在这种情况下有合理理由相信域名冲突会对人类生命造成迫在眉睫的明确威胁。NGPC 认同 SSAC 关于扩大可触发应急响应情况的范围的建议。但 NGPC 指出,此风险的严重程度(如在其他情况下一样)可以从多个角度衡量;必要时,将在受影响的各方之间(即在域名于公共 DNS 中被授权之前使用该域名的一方与注册该域名的一方)做出裁决。商业利益可能会为了竞争优势而尝试"博取"更广泛的机制。在全球范围内,"国家安全"、"法律与秩序"和"关键经济过程"等概念很难被一致认同。另一方面,注重对人类生命造成的威胁是一个更加客观的标准。

      此外,最终域名冲突框架纳入了一个应急响应措施,以解决新授权的 gTLD 因作为无点域名使用而导致使用冲突,进而对人类生命造成迫在眉睫的明确威胁的罕见情况。如果发生这种情况,ICANN 会与注册局运营商以及 ICANN 的根域管理合作伙伴一起推翻新的授权。只有在为期 90 天的通配符控制性中断期间可以这么做。在此期间,TLD 下不会存在已激活的域名("nic"除外)。一旦伤害减轻后,gTLD 注册局运营商可能会再次申请授权。如 SAC062 和 JAS 研究和域名冲突框架报告所述,推翻新授权是一种极端手段,应在通配符控制性中断期间对人类生命造成迫在眉睫的明确威胁的极端情况下才能这么做。

      对社群有积极或消极影响吗?对 ICANN(战略计划、运营规划、预算)、社群和/或公众会产生财政影响/后果吗?是否存在与 DNS相关的任何安全、稳定或弹性问题?

      SAC057 和域名冲突研究发现了若干与 DNS 相关的安全性问题。最终域名冲突框架(已根据社群意见进行修订)和 SSAC 在 SAC066 中提出的建议,为推动新 gTLD 授权流程提出了一个安全、稳定的计划。

      落实最终域名冲突框架所述措施时可能会产生一些额外成本,因此最终域名冲突框架可能对 ICANN、社群或者公众带来一些财务影响。该框架还将针对可能的受影响方举行一次外展活动,以帮助他们识别和管理其网络中的域名冲突事件。这一外展活动可能需要占用额外资源。

      为了行使组织管理职能,ICANN 已将 JAS 研究中的域名冲突框架公开发布。有关公众意见的报告,请参阅:

      https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 230 KB]。

resolutions-new-gtld-30jul14-zh.pdf  [217 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."