Skip to main content
Resources

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

本页面还提供其他语种:

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

 

  1. 主要议程
    1. 新 gTLD 冲突事件管理
      1. 第 2013.10.07.NG01 和 2013.10.07.NG02 号决议的理由

 

  1. 主要议程:

    1. 新 gTLD 冲突事件管理

      p>鉴于 2013 年 3 月 15 日,ICANN 安全与稳定咨询委员会 (SSAC) 公布了 SAC 057:SSAC 关于内部名称证书的咨询报告。

      鉴于为了回应 SAC 057 中提出的各种问题,ICANN 理事会要求主席兼首席执行官与 SSAC 一同就尚未在公共 DNS 根级得到授权的 TLD 的使用开展一项研究(以下简称"域名冲突研究")。

      鉴于"域名冲突研究"以及一项旨在管理"域名冲突研究"中发现的风险的提案(以下简称"提案")已于 8 月 5 日至 9 月 17 日公开发布以征求公众意见。此提案现已根据公众意见进行了修订。

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

      兹此发布第 2013.10.07.NG01 号决议:NGPC 要求通用域名部门主任落实一项旨在妥善管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件的提案,以便考虑 SSAC 和其他专家和利益主体可能提出的其他意见和建议。提案的完整内容请参阅附录 1 [PDF, 840 KB]:"新 gTLD 冲突事件管理计划"。

      第 2013.10.07.NG02 号决议:NGPC 要求 ICANN 主席兼首席执行官(或者通用域名部门主任)妥善落实计划的外展活动。NGPC 还向理事会建议:(1) ICANN 理事会风险委员会仔细审查这一事务并向理事会提交报告,然后定期就此事务进行审查和报告;(2) 理事会要求 ICANN 主席兼首席执行官就在根区管理域名冲突制订一项长期计划;以及 (3) 理事会要求 ICANN 主席兼首席执行官与机构群体一同就保留和衡量根服务器数据制订一项长期计划。

      第 2013.10.07.NG01 和 2013.10.07.NG02 号决议的理由

      NGPC 为什么要马上解决此问题?

      在"SAC 057:SSAC 关于内部名称证书的咨询报告"中,ICANN 安全与稳定咨询委员会 (SSAC) 发现了一种存在风险的证书颁发机构 (CA) 行为。这种行为如果被大规模利用,可能会对安全互联网通信的隐私和完整性造成严重影响,并可能危及新 gTLD 计划。因此,SSAC 建议 ICANN 立即采取措施以缓解此风险。SAC 057 中发现的问题属于一类较普遍的问题。在此类问题中,一方在专用网络中使用了包含未授权 TLD 的域名,在落实新 gTLD 计划后,此 TLD 将在根区得到授权。

      理事会之前曾要求 ICANN 主席兼首席执行官就当时尚未在公共 DNS 的根级得到授权的 TLD 的使用开展一项研究。该研究还考虑了申请与此类使用相关的新 gTLD 字符串的潜在安全影响。

      该项研究业已完成,并于 2013 年 8 月 5 日发布(即"域名冲突研究")。一项旨在管理"域名冲突研究"中发现的风险的提案(即"提案")亦于当日至 9 月 17 日公开发布以征求公众意见。目前,NGPC 正在考虑采纳已根据公众意见予以修订的此项提案。采纳并落实此提案有助于 ICANN 安全、稳定地推动新 gTLD 的授权流程。

      考虑了哪些提案?

      NGPC 考虑的提案(请参阅本决议的附录 1)就管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件提出了一项计划。此提案已根据于公众意见征询期内收到的公众意见和建议进行了修订。修订后的提案的内容主要包括开展另外一项研究,以制订域名冲突事件管理框架。此框架将包含适当的参数和流程,以评估域名冲突事件导致有害结果的可能性和严重性。此类参数可能包括 DNS 申请数量、DNS 申请类型、查询类型、查询源的多样性以及内部名称证书中出现的次数。此框架将指定一套冲突事件评估方法和相应的解决措施(如适用),这些措施将由 ICANN 或 TLD 申请人根据二级域名 (SLD) 予以落实。相关二级域名请参阅 "Day in the life of the Internet"(互联网时代,DITL)数据集。

      该提案还使得注册管理执行机构能够选择在收到 SLD 冲突事件评估报告之前继续授权(需根据既定流程和程序行事)。如果注册管理执行机构选择这种替代授权方式,则必须在执行冲突评估后初步拦截 DITL 数据集中出现的所有 SLD。

      另外,此提案还提出了一项建议流程,以便受影响方报告域名冲突事件,并要求拦截导致了显著且严重损害的 SLD。这一流程旨在缓解研究数据集中未发现、但可能存在严重影响的域名冲突事件带来的风险。

      最后,提案还针对可能受影响方建议了一项外展活动,以便帮助他们识别并管理其网络中的域名冲突事件源头。ICANN 可能邀请同样关注此问题的其他方和机构群体成员参加外展活动。NGPC 决议要求 ICANN 主席兼首席执行官妥善落实这一计划的外展活动。

      有关此提案的完整内容,请参阅附录 1 [PDF, 840 KB]。

      NGPC 还建议 ICANN 理事会要求 ICANN 主席兼首席执行官就管理与新 TLD 授权相关的域名冲突风险制订一项长期计划,并与机构群体一同就保留和衡量根服务器数据制订一项长期计划。

      NGPC 还向 ICANN 理事会建议:ICANN 理事会风险委员会应定期仔细审查此事务并向理事会提交报告。

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

      ICANN 在于南非德班举行的 ICANN 会议期间发布了"域名冲突研究"中的发现。此外,ICANN 还启动了一个公众意见征询论坛,邀请各群体对"域名冲突研究"和"提案"发表意见和建议,论坛开放期为 2013 年 8 月 5 日至 9 月 17 日。此次公众意见征询共收集到 75 条意见和建议。有关公众意见报告汇总以及完整的意见和建议内容,请参阅 http://forum.icann.org/lists/comments-name-collision-05aug13/。工作人员根据公众的意见和建议修订了提请 NGPC 考虑的提案,进一步完善了旨在管理域名冲突事件的计划。

      机构群体有什么疑虑或提出了哪些问题?

      部分群体成员提出一个颇具普遍性的疑虑:新 gTLD 流程早已提上日程,为何这么晚才开始处理域名冲突问题?ICANN 为何没有及早处理此事? 有些评论人员表示时间不够,他们要求延长公众意见征询期,以便群体成员有更多时间研究这些问题,从而提供更有建设性的意见和建议。

      还有群体成员认为"域名冲突研究"中提及的风险可能被夸大了。他们表示在所有 TLD DNS 服务器请求中,仅 3% 的请求与新 gTLD 计划实际考虑的字符串存在冲突。还有人认为延期 3-6 个月授权并不能保证缓解问题。

      有些评论人员指出之前扩展 TLD(例如 .xxx、.asia)的举措并没有导致任何已知问题。根据这些成功的授权案例,他们认为除了两个最有风险的字符串外,其他字符串的授权都不必延期。还有人表示目前不存在推迟"低风险"和"无法估算风险"两类 TLD 申请的授权的正当理由。

      还有群体成员就"域名冲突研究"中使用的样本数据或风险评估方法的有效性或适用性发表了意见。他们指出,在评估风险时,仅计算每条字符串的申请数量是不够的,并建议在考虑申请频率的同时还考虑冲突后果的严重性。他们还认为,"域名冲突研究"中缺失关键数据,即现有 TLD 中不存在的域名 (NXD) 的流量,或 TLD 中接收 NXD 流量(属于"无法估算风险"类别)的特定子域中不存在的域名的流量。还有人对研究方法提出了质疑。他们表示通过设置阈值的方法将字符串划分为"低风险"和"无法估算风险"类别(例如 80%/20%)的做法过于武断。

      有些评论人员建议 ICANN 就防范域名冲突事件的最佳措施积极、主动地向全球各地的企业提供培训。

      还有评论人员认为 ICANN 必须做好延期将新 gTLD 纳入 DNS 中的准备,因为各种深入、全面的研究表明这存在域名冲突风险。仅当基本上可消除相应 gTLD 字符串的域名冲突风险时方可取消这种延期。

      理事会审查了哪些重要材料?

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

      在衡量是否采纳此提案以管理域名风险事件时,NGPC 考虑了许多重要因素。以下是这些因素中 NGPC 认为至关重要的:

      • NGPC 考虑了 SSAC 在 SAC 057 中所提的建议。
      • 许多评论人员表示,在评估域名冲突风险时,仅考虑 DNS 申请频率是不够的。在确定风险水平时,ICANN 必须综合衡量多种参数(例如申请频率、查询类型、申请类型等)。还有人认为 ICANN 以武断地方法划分字符串的风险类别。ICANN 同意在评估风险时除了考虑申请频率,还应考虑其他参数,特别是域名冲突风险可能导致的损害,并表示在开展研究时,将综合衡量其他建议的参数以评估域名冲突事件的可能性和影响(例如导致的损害)。
      • 还有人就域名冲突事件的风险管理提出了新设想。例如,有群体成员建议临时拦截特定二级域名 (SLD),以在推动新 gTLD 授权流程的同时,保留在可能泄漏至公共 DNS 的专用网络中使用新 gTLD 域名的各方的 DNS 解析器预期的 DNS 行为。ICANN 工作人员也认为临时拦截 DITL 数据中出现的 SLD(即禁止在新授权的 TLD 中解析这些域名)可确保当前会泄漏到公共 DNS 中的相应 DNS 申请将继续响应(显示"域名错误"(NXDOMAIN),而且该措施有助于显著降低域名冲突导致损害的可能性。提案中采纳了这一建议。
      • 还有群体成员要求延长公众意见征询期,以便各群体有更多时间研究其网络中存在的风险。ICANN 表示,修订后的提案采纳了临时拦截 SLD 的措施,这一措施将为可能的受影响方提供足够时间研究其网络中的问题,而不会受到新 gTLD 授权流程的影响。此外,为了解决尚未临时拦截、但可能造成严重损害的 SLD 的影响,注册管理执行机构将落实一个流程,以便受影响方报告造成严重损害的域名冲突事件,并要求暂停相关域名。
      • 还有人认为 ICANN 应举行外展活动,向可能的受影响方介绍域名冲突事件及其潜在影响。ICANN 同意这一建议,并已在修订后的提案中提出了举行外展活动。

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

      SAC057 和"域名冲突研究"发现了若干与 DNS 相关的安全性问题。这份已根据群体意见和建议修订的提案为推动新 gTLD 授权流程提出了一个安全、稳定的计划。NGPC 要求通用域名部门经理推动落实此提案的行动对机构群体有着积极影响。借助其方法,当授权申请的 TLD 可能带来的损害较小时,ICANN 能够继续新 gTLD 授权流程。

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

      为了行使组织管理职能,ICANN 已将"域名冲突研究"和旨在管理域名冲突风险的"提案"公开发布。有关公众意见和建议报告,请参阅:http://forum.icann.org/lists/comments-name-collision-05aug13/

resolutions-new-gtld-07oct13-zh.pdf  [179 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."