Skip to main content
Resources

会议记录 | 新 gTLD 计划委员会例行会议

本页面还提供其他语种:

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

 

说明:2012年 4月 10日,理事会成立了新 gTLD计划委员会,该委员会由与新 gTLD计划不存在冲突的理事会所有投票成员组成。委员会获得理事会的全部授权(受法律、组织条例、章程或 ICANN利益冲突政策中限制条件的约束),行使理事会级别的权力处理与新 gTLD计划有关的所有问题。委员会权力的全部范围在其章程中列出,请参阅 http://www.icann.org/en/groups/board/new-gTLD

ICANN理事会的新 gTLD计划委员会于 2013年 10月 7日 13:00 UTC召开了一次电话特别会议。

委员会主席 Cherine Chalaby即刻宣布会议正式开始。

除主席外,以下理事也参加了全部或部分会议:Fadi Chehadé(ICANN总裁兼首席执行官)、Chris Disspain、Bill Graham、Olga Madruga-Forti、Erika Mann、Gonzalo Navarro、Ray Plzak、George Sadowsky、Mike Silber和吴国维。

IETF联络员 Jonne Soininen作为无投票权的委员会联络员出席了会议。Heather Dryden作为委员会观察员出席了会议。TLG联络员 Francisco da Silva因未能参加会议而表示歉意。

以下 ICANN工作人员参加了全部或部分会议:Akram Atallah(通用域名部门主任)、John Jeffrey(总顾问兼秘书长)、Megan Bishop、Samantha Eisner、Dan Halloran、Jamie Hedlund、Cyrus Namazi、Karine Perset、Erika Randall、Amy Stathos和 Christine Willett。

Paul Mockapetris作为特邀观察员参加会议。针对主要议程中的事项 1,Ram Mohan作为特邀观察员参加会议。

以下是 2013 年 10 月 7 日新 gTLD 计划委员会会议的记录。

  1. 主要议程
    1. 新 gTLD 冲突事件管理

 

  1. 主要议程:

    1. 新 gTLD 冲突事件管理

      应主席要求,Paul Mockapetris 向委员会提供了关于域名冲突问题的意见。Paul 从历史的角度分析了不完全合格域名的使用,指出电子邮件方面过去存在的域名冲突问题,并介绍了一些国家/地区代码。Paul 指出模糊不清必然对 DNS 的安全不利,并建议 ICANN 在引入新域名时尽其所能降低模糊性。Paul 认为提议的《新 gTLD 冲突事件管理计划》能够有效降低模糊性,并建议 ICANN 控制 TLD 的发展速度。

      应主席要求,Ram Mohan 向委员会提供了关于"冲突事件管理计划"的其他技术指导。Ram 表示他完全支持这一计划,并建议委员会考虑该计划是否:(1) 技术可靠;(2) 经得起严格检查;(3) 解决了原本打算解决的问题;(4) 需要其他要素。

      Ram 认为该计划技术可靠,例如,他指出该计划纠正了以往分析的一些不足,因为新计划解决了冲突的严重程度区分问题,并删除了风险分类(机构群体大多认为分类过于武断)。

      Ram 建议,委员会应清楚地划分该计划要求的适当外展等级。Erika Mann 和 Jonne Soininen 也认为参数划分应该更加清楚。

      Ram 指出,提议的计划包括使其经得起考验的参数,但是机构群体可能更加关注如何研究冲突事件严重性的详细信息。

      Ram 指出,保留已知有冲突的二级域名是个不错的主意,分析计划提议的各字符串有技术和安全机构群体的大力支持。

      Ram 指出计划应该解决的其他事项,其中包括研究制定减少公众使用未分配 TLD 字符串的长期措施、与 IAB 和 IETF 制定保留专用字符串的计划、研究 ccTLD 授权的影响、制定用于衡量进一步推荐所用根服务器数据的计划。Ray Plzak 建议,数据收集衡量应不仅限于域名,并应研究 IN-ADDR.ARPA、ARPA 域名和数字。

      委员会的多名成员同意该计划需要包含这些额外要素。

      Ram 表示,由于域名冲突问题不仅仅是新 gTLD 问题,因此可能应由理事会下属的委员会进行适当监管。Mike Silber 询问由理事会风险委员会监管这一问题是否合适。Ray 和主席都同意这一问题应由理事会风险委员会监管。

      Olga Madruga-Forti 询问,适当情况下,ICANN 是否进行有条件授权,作为解决冲突事件问题的一个手段。Olga 阐明了有条件授权与试点授权之间的区别。Ram 询问试点授权的意义,并指出两方面的担忧:获取更多来自试点授权的数据是否可以提供简化授权决定的信息,试点授权是否会降低一些 DNS 组件的稳定性。

      GDD 主任指出,由于危害不是由初始 TLD 授权引起,而可能在激活二级域名时造成,随时都有可能出现,因此试用授权可能不能有效降低风险。

      George Sadowsky 询问,在机构群体中提出的关于谨慎授权的方法提案在技术上是否可靠。GDD 主任指出,机构群体正在讨论的多项缓解计划,例如试点授权和来自 IAB 的 Kolkman 报告,可能用在提案即将制定的缓解计划中。

      Mike Silber 建议,提案需要表达出对机构群体意见严肃考虑并非置若罔闻的基调。Erika 对此表示赞同。

      委员会讨论了对决议的修改,以解决建议纳入提案的其他事项,并审查了修订后的决议。Gonzalo Navarro 对于需要额外时间审核决议表示担忧。

      Chris Disspain 提出以下决议,并得到 Mike Silber 的支持。

      委员会随后采取了以下行动:

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

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

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

      鉴于 NGPC 根据理事会于 2012 年 4 月 10 日的授权开展此项工作,针对提出的任何有关新 gTLD 计划的问题行使 ICANN 理事会的权力。

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

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

      九名委员会成员投票赞成第 2013.10.07.NG01 – 2013.10.07.NG02号决议。Gonzalo Navarro和 Ray Plzak对这些决议投弃权票。决议通过。

      放弃对决议的投票权时,Gonzalo Navarro 表示,考虑到决议的重要性,虽然委员会看来同意提案的内容,但是具体措词非常复杂和重要而且需要额外的时间进行考虑。Ray Plzak 表示他弃权的原因与此相同。Olga Madruga-Forti 在决议问题的复杂性上与 Gonzalo 的意见一致。

      第 22013.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, 844 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/

      主席宣布会议结束。

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