Skip to main content
Resources

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

本页面还提供其他语种:

说明:2012 年 4 月 10 日,董事会成立了新 gTLD 项目委员会,该委员会由与新通用顶级域名项目不存在冲突的董事会所有投票成员组成。委员会获得董事会的全部授权(受法律、企业设立章程、章程或 ICANN 利益冲突政策中限制条件的约束),行使董事会的权力以处理所有可能因新通用顶级域名项目而产生的问题。委员会权力的全部范围在章程中列出,请参阅http://www.icann.org/en/groups/board/new-gTLD.

ICANN 董事会的新 gTLD 项目委员会于 2014 年 7 月 30 日世界协调时 21:30 召开了一次例行会议。

委员会主席谢琳·查拉比 (Cherine Chalaby) 宣布会议正式开始。

除主席外,以下董事也参加了全部或部分会议:法迪·切哈德(Fadi Chehadé,ICANN 总裁兼首席执行官)、斯蒂芬·克罗克(Steve Crocker,董事会主席)、克里斯·迪斯佩恩 (Chris Disspain)、雷·普拉扎 (Ray Plzak)、麦克·西尔柏 (Mike Silber) 和吴国维。

希瑟·德莱顿 (Heather Dryden)、比尔·格拉汉姆 (Bill Graham)、 布鲁诺·朗万 (Bruno Lanvin)、奥尔加·马德鲁加-福蒂 (Olga Madruga-Forti)、埃里卡·曼 (Erika Mann)、贡萨洛·纳瓦罗 (Gonzalo Navarro)、乔治·萨多夫斯基 (George Sadowsky) 和苏珊娜·伍尔夫 (Suzanne Woolf) 因未能参加会议而表示歉意。

IETF 联络人约恩内·索恩宁 (Jonne Soininen) 作为委员会无表决权的联络人出席了会议。

秘书长:约翰·杰弗里(John Jeffrey,总法律顾问兼秘书长)。

以下 ICANN 高级管理人员和员工参加了全部或部分会议:阿克兰·阿特拉先生(Akram Atallah,全球域名部门总裁)、弗朗西斯科·阿瑞亚斯先生(Francisco Arias,全球域名部门技术服务主管)、梅根·比舍朴女士(Megan Bishop,董事会支持协调人)、米歇尔·布莱特女士(Michelle Bright,董事会支持部主任)、莎曼珊·艾斯内女士(Samantha Eisner,资深法律顾问)、艾伦·格罗根先生(Allen Grogan,首席合同法律顾问)、赛勒斯·纳马齐先生(Cyrus Namazi,域名系统行业合作副总裁)、埃里卡·兰德尔女士(Erika Randall,顾问)、艾米·斯塔索斯女士(Amy Stathos,副总法律顾问)及克里斯汀·威雷特先生(Christine Willett,gTLD 运营副总裁)。

以下是 2014 年 7 月 30 日新 gTLD 项目委员会会议的记录。

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

 

  1. 主要议程:

    1. 域名冲突管理框架

      委员会继续讨论之前会议的议题,即制定框架以解决新 gTLD 和现有供私人使用的相同字符串之间的冲突。阿克兰·阿特拉先生 (Akram Atallah) 简要介绍了委员会之前关于域名冲突的讨论,并概述了域名冲突缓解框架提案。

      委员会继续审议了与 GNSO 合作的可能性,以便考量是否应着手开展制定长期计划以解决域名冲突问题的政策工作。雷·普拉扎指出决议提案将解决相关疑虑。克里斯·迪斯佩恩询问了如果框架被采纳,注册局运营商开始实施控制性中断期的时间表。

      雷·普拉扎提出决议提案,并得到吴国维的支持。委员会随后采取了以下行动:

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

      鉴于冲突事件管理计划要求进行相关后续研究,为制定域名冲突管理框架提供参考。

      鉴于 ICANN 于 2014 年 2 月 26 日公布了 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 第一阶段报告的意见,该意见向董事会提供了关于 JAS 研究和域名冲突框架中所提框架的意见和建议。

      鉴于提交给 NGPC 以供考量的域名冲突框架提案考虑了 SSAC 在 SAC066 中提供的建议,以及其他专家和利益相关方的建议,包括来自 JAS、公众意见和 ICANN 会议社群讨论的建议。

      鉴于 NGPC 对社群提出的的这一意见表示肯定:需要确保注册局根据授权替代路径报告拦截的所有域名都遵循新 gTLD 项目建立的权利保护机制。

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

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

      兹发布第 2014.07.30.NG01 号决议,NGPC 采纳域名冲突管理框架 <https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf> [PDF, 635 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 号决议。比尔·格拉汉姆、布鲁诺·朗万、奥尔加·马德鲁加-福蒂、埃里卡·曼、乔治·萨多夫斯基和贡萨洛·纳瓦罗未能对这些决议投票。决议通过。

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

      为什么 NGPC 要在当下考虑此问题?

      NGPC 目前的行动是延续它之前为解决域名冲突问题采取的行动。特别是在 2013 年 10 月 7 日,NGPC 采取了行动,要求全球域名部门总裁落实一项旨在妥善管理新 gTLD 和现有供私人使用的相同字符串之间的冲突事件的提案,以便考虑安全与稳定咨询委员会 (SSAC) 和其他专家及利益相关方可能提出的其他意见和建议。提案的完整内容请参阅 "新通用顶级域名冲突事件管理计划"(简称 "冲突事件管理计划")。冲突事件管理计划的核心要素要求 ICANN 进行进一步的研究调查,以制定域名冲突管理框架。该框架旨在详细说明一系列冲突事件评估,以及 ICANN 或新 gTLD 申请人可能需要实施的相应缓解措施。

      为落实 NGPC 2013 年 10 月 7 日的行动,ICANN 于 2014 年 2 月 24 日公布了由 JAS Global Advisors(以下简称 "JAS")起草的研究,题为 "缓解 DNS 域名空间冲突风险:全球互联网 DNS 域名空间中的域名空间冲突研究及风险缓解框架,第一阶段报告"(以下简称 "JAS 研究和域名冲突框架")。JAS 研究和域名冲突框架提供了一组建议,说明减少当前和未来 DNS 域名空间冲突的综合框架,提醒运营商与 DNS 域名空间相关的潜在问题,提供关键(例如生命安全)系统受到不利影响时的应急响应能力。此外,SSAC 在SAC 066:SSAC 关于缓解 DNS 域名空间冲突风险 JAS 第一阶段报告的意见 [PDF, 306 KB] 中就 JAS 报告包含的域名冲突框架提案向董事会提出了意见和建议。

      此次 NGPC 将采纳冲突事件管理计划中要求的最终版框架(以下简称 "最终域名冲突框架"),即 2014 年 7 月 30 日确定的域名冲突管理框架 https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 635 KB]。最终域名冲突框架以 JAS 研究和域名冲突框架中的框架为基础构建,并根据 SAC066 中的建议、公众意见及 ICANN 伦敦会议期间的其他社群反馈进行了进一步优化。采纳并落实最终域名冲突框架将有助于 ICANN 继续安全、稳定地推动新 gTLD 的授权流程。

      考虑了哪些提案?

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

      对注册局的一般要求:

      • 要求在 TLD 授权起的头两年有效期内,在 ICANN 公布域名冲突报告的两小时内执行报告内容。

      • 要求执行 "控制性中断",作为通知措施提醒各方他们可能将查询从私营域名空间泄露到公共 DNS。控制性中断需要连续执行(即非间歇性),并持续 90 天。一般来说,如果 TLD 在规定的截止日期前获得授权,注册局运营商将需要使用 MX、SRV、TXT 和 A 记录,对拦截清单中包含的二级域名执行控制性中断。对于在规定的截止日期后授权的 TLD,注册局运营商将需要使用通配符方法执行控制性中断。控制性中断(针对 IPv4)将使用回送地址 (127.0.53.53)。

      对 ICANN 的要求:

      • 在 IETF 内部并与其他相关的技术社群合作,找出与 IPv4 "回送"保留前缀的通知具有类似功能的 IPv6 通知机制。

      • 无限期推迟授权 .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 还就 JAS 研究和域名冲突框架中的域名冲突框架提案咨询了 SSAC,SSAC 通过 SAC066 向董事会提供了建议。此外,ICANN 还在其伦敦会议期间发布了最终域名冲突框架提案。

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

      JAS 研究和域名冲突框架在公共评议期收到了各种来源提交的 28 条意见,其中包括新通用顶级域名申请人及其附属公司、不直接隶属于申请人的公司、个人科技专家和与 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 和其他相关技术社群合作,找出与 IPv4 "回送"保留前缀的通知具有类似功能的 IPv6 通知机制。

      • 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]。

    主席宣布会议结束。

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