Skip to main content
Resources

批准的董事会决议 | ICANN 董事会例行会议

本页面还提供其他语种:

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

  1. 认可议程:
    1. 批准董事会会议记录
    2. 将代表白俄罗斯的西里尔文字域名 бел (bel) 授权给 Reliable Software Inc.
    3. 删除代表葡属帝汶的 .TP 顶级域
    4. GNSO 理事会政策建议 — 注册服务机构域名转让政策 D 部分
    5. 收集新 gTLD 项目度量指标为关于竞争、消费者信任和选择的未来 AoC 审核提供支持的建议
    6. 安全与稳定咨询委员会 (SSAC) 成员连任
    7. 任命杰夫•胡森 (Geoff Huston) 到安全与稳定咨询委员会 (SSAC) 任职
    8. 感谢离任的社群成员
    9. 感谢 第 52 届 ICANN 会议的赞助商
  2. 主要议程:
    1. 在 gTLD 二级释放双字母代码

 

  1. 认可议程:

    1. 批准董事会会议记录

      第 2015.02.12.01 号决议:董事会批准 2014 年 11 月 17 日和 2014 年 12 月 3 日的 ICANN 董事会会议记录。

    2. 将代表白俄罗斯的西里尔文字域名 бел (bel) 授权给 Reliable Software Inc.

      第 2015.02.12.02 号决议:根据 IANA 职能合同中所述的职责,ICANN 已审核并评估将 бел 国家或地区顶级域授权给"Reliable Software Inc."的申请。文件材料显示,在评估此申请时,工作人员严格遵守了相应流程。

      第 2015.02.12.03 号决议:董事会指示,根据《ICANN 章程》第 III 条第 5.2 款,为了履行合同义务,决议、初步报告或会议记录中的部分理由目前不宜公诸于众,应等待适当时机再予以公布。

      第 2015.02.12.02 - 2015.02.12.03 号决议的理由

      为什么董事会现在要解决此问题?

      根据 IANA 职能合同的要求,ICANN 工作人员已评估一个授权 ccTLD 的申请,且目前正在准备报告,以提请董事会审核。提请董事会审核的目的是确保 ICANN 工作人员严格遵守相应流程。

      正在考虑的提案是什么?

      该提案旨在批准向 IANA 部门提交的一项申请,该申请希望创建国家/地区代码顶级域并将主办组织(也称为管理者或受托者)的角色分配给 Reliable Software Inc.。

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

      在授权申请的评估过程中,ICANN 工作人员咨询了申请人和其他利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其在本地互联网社群中的影响力。

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

      工作人员未收到社群就此申请提出的重要问题或疑虑。

      董事会审核了哪些重要材料?

      [已删减 — 敏感授权信息]

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

      董事会未发现此申请存在任何特定隐患。

      是否会对社群产生积极或者消极影响?

      及时批准符合各种公共利益标准的国家或地区代码域管理者对于 ICANN 整体工作会有积极影响,对于该域所服务的当地社群也会有积极作用,同时还可体现 ICANN 积极履行 IANA 职能合同中所述的职责。

      是否会在财务方面对 ICANN(战略计划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      管理 DNS 根域中的国家/地区代码授权是 IANA 的职责,授权行动不会对预先计划的开支有任何重大影响。评估国家/地区代码顶级域在特定国家或地区内部所产生的财政影响并不是 ICANN 的职责。

      是否存在与 DNS 相关的任何安全性、稳定性或弹性问题?

      ICANN 认为此申请不会对安全性、稳定性或弹性造成明显不利影响。这属于组织管理职能,无需征询公众意见。

    3. 删除代表葡属帝汶的 .TP 顶级域

      鉴于 ISO 3166-1 标准已删除代表东帝汶的两字符代码"TP",改用"TL"代码。

      鉴于 .TL 域名在 2005 年经授权取代 .TP 域名,且已有多年过渡时间让 .TP 注册人迁移至新的国家/地区代码顶级域。

      鉴于 ICANN 收到东帝汶政府的确认函,支持从 DNS 根区最终删除 .TP 授权。

      兹此发布第 2015.02.12.04 号决议:从 DNS 根区删除 .TP 授权。

      第 2015.02.12.04 号决议的理由

      为什么董事会现在要解决此问题?

      .TP 顶级域名计划在 2015 年 2 月 28 日前从 DNS 根区中删除。作为 .TP 运营商的东帝汶政府确认同意从 DNS 根区删除 .TP。

      正在考虑的提案是什么?

      该提案旨在批准向 IANA 提交的一项申请,该申请希望从 DNS 根区删除 .TP(葡属帝汶)顶级域授权。

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

      在顶级域删除申请的评估过程中,ICANN 工作人员咨询了当前运营商和其他利益相关方。删除流程中,当前运营商需要描述遵循的步骤,以确保顶级域的删除不会对互联网稳定性产生计划外的不利影响。

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

      工作人员未收到社群就此申请提出的重要问题或疑虑。东帝汶政府确认 .TP 顶级域不再具有实际用途。

      是否存在与 DNS 相关的任何安全性、稳定性或弹性问题?

      ICANN 认为此申请不会对安全性、稳定性或弹性造成明显不利影响。这属于组织管理职能,无需征询公众意见。

    4. GNSO 理事会政策建议 — 注册服务机构域名转让政策 D 部分

      鉴于 2013 年 1 月 17 日,GNSO 理事会就注册服务机构域名转让政策 D 部分(IRTP D 部分)启动政策制定流程 (PDP),以解决六个章程问题,详情请访问 https://community.icann.org/display/ITPIPDWG/3.+WG+Charter

      鉴于 PDP 遵循了章程中所规定的 PDP 步骤,最终于 2014 年 9 月 25 日提交了《最终报告》。

      鉴于 IRTP D 部分工作组 (WG) 就与章程中概述的六个问题相关的建议达成全体共识。

      鉴于 GNSO 理事会审查讨论了 IRTP D 部分工作组的建议,并于 2014 年 10 月 15 日通过一致投票采纳了这些建议(请参考: http://gnso.icann.org/en/council/resolutions#20141015-1)。

      鉴于 GNSO 理事会投票达到并超过了为 ICANN 缔约方增加新义务所需的投票门槛(亦即绝大多数票)。

      鉴于在 GNSO 理事会投票后,就批准的建议开放了公共评议期,并就所征集到的意见进行了总结和考虑 (https://www.icann.org/public-comments/irtp-d-recommendations-2014-10-20-en)。

      兹此发布第 2015.02.12.05 号决议:董事会通过关于修改注册服务机构域名转让政策(详见 http://www.icann.org/en/transfers/policy-en.htm )和转让争议解决政策(TDRP,详见 https://www.icann.org/resources/pages/tdrp-2012-02-25-en)的 GNSO 理事会政策建议。

      第 2015.02.12.06 号决议,董事会指示总裁兼首席执行官或其指定人员制定并完成关于这些建议的实施规划,继续就实施工作与 GNSO 实施审核小组和社群展开交流和合作。

      第 2015.02.12.05 - 2015.02.12.06 号决议的理由

      为什么董事会现在要解决此问题?

      注册服务机构域名转让政策 (IRTP) 是一项已于 2004 年采纳的共识性政策,它为注册人提供了一种在注册服务机构之间转让域名的直接方式。GNSO 理事会成立了四个工作组(A 部分到 D 部分)审核该政策并考虑对其进行各种修订。

      IRTP D 部分的政策制定流程是四个一系列政策制定流程中的最后一个,该系列分别针对现有政策中的不同改进领域。

      IRTP D 部分《PDP 最终报告》获得了 IRTP D 部分工作组和 GNSO 理事会的一致支持。公共评议期结束后,根据《ICANN 章程》附录 A,下一步是由 ICANN 董事会考虑这些建议。

      正在考虑的提案是什么?

      正考虑通过以下政策建议:

      建议 #1 - 工作组建议将报告要求纳入 TDRP 政策。争议解决服务提供商 (DRP) 1 作出的所有裁决结果都应该按照 UDRP 当前采用的做法公布到提供商的网站上,特殊情况除外。这类例外情况必须由 DRP 申请、ICANN 合同合规部门根据各个案例的情况给予批准。工作组建议发布遵照亚洲域名争议解决中心 (ADNDRC) 示例编制的报告。2 此类报告应至少包括以下内容:

      1. 处于争议中的域名;
      2. 争议当事方的相关信息;
      3. 案例裁决全文;
      4. 裁决执行日期。

      此公开要求不适用于在实施本建议前发生的 TDRP 裁决。

      建议 #2 - 工作组建议修订 TDRP 以纳入此 UDRP 修订版的有关内容:

      "相关争议解决服务提供商应报告依据 TDRP 启动的转让争议解决流程的所有裁决。根据该政策作出的所有裁决都将完整地公布在互联网上,只有争议解决专家组在特殊情况下决定编辑裁决内容时除外。任何情况下,如果某项投诉被认定为恶意投诉,则应完整公布对其作出的裁决。"

      建议 #3 - 工作组建议对 TDRP 进行修订,纳入以下内容或与其含义相当的内容:"根据转让争议解决政策中争议解决流程的规定,如果接手注册服务机构通过无效转让从登记在册注册服务机构那里获得注册提供权,则从接手注册服务机构到第三方注册服务机构的转让以及所有其他后续转让均无效。"

      建议 #4 - 工作组建议,如果通过 TDRP 程序发现了违反 IRTP 的域名转让,应在执行该违规转让前直接将域名退回给登记在册的注册服务机构和注册人。

      建议 #5 - 工作组建议将启动 TDRP 的法定时效从目前的首次转让后 6 个月延长至首次转让后 12 个月。

      这样,即使注册人不再接收其注册服务机构发出的年度 WDRP 通知,仍有机会发现欺诈性转让。

      建议 #6 - 工作组建议,如果根据 TDRP 发起强制执行请求,则在等待处理这类请求的过程中,应"锁定"相关域名,不得进行进一步转让。相应地,应将"TDRP 行动"和"URS 行动"添加至 IRTP 中拒绝转让理由列表的第二点中(第 3 节);同时相应地修改 IRTP 和 TDRP 的内容。3

      TDRP 以及注册服务机构、注册管理机构和第三方争议解决服务提供商指导手册也应该进行相应的修改。工作组指出,一旦开始实施 UDRP 锁定流程,应按 UDRP 规定的方式执行锁定。

      建议 #7 — 工作组建议在 TDRP 中新增一份定义列表(最终报告附录 F),使政策更清晰易懂。

      建议 #8 — 工作组建议不要在当前 TDRP 中制定适用于注册人的争议解决选项。

      建议 #9 — 工作组建议工作人员与 IRTP C 部分实施审核小组密切合作,确保 IRTP C 部分注册人间域名转让建议得以实施,同时确保了解是否需要建立争议解决机制以解决最终报告附录 C 中的使用案例。一旦这类政策得到实施,应对其运作情况进行密切监测,必要时应编制一份问题报告来评估是否需要制定注册人间域名转让争议解决政策。另请参见下文中的建议 #17 和 #18。

      建议 #10 — 工作组建议修订 TDRP,取消 TDRP 的第一层(注册管理机构层)。

      ICANN 应持续监督 TDRP 的应用情况,如果取消作为一级争议解决服务提供商的注册管理机构层似乎对这一争议解决机制造成障碍,则将来应启动相关政策工作,重新恢复注册管理机构层。另请参见下文中的建议 #17。

      建议 #11 — 工作组建议 ICANN 采取必要步骤,在 ICANN 网站上突出显示与违规转让争议有关的信息,并确保此类信息的呈现方式简单明了,方便注册人访问。

      此建议应结合建议 #12(参见下文)一起查看。

      建议 #12 — 工作组建议 ICANN 创建并维护一个用户友好的一站式网站,网站上包含与具有争议的转让和注册人可以采取的补救措施相关的全部信息。此类网站应设置为可以从 ICANN"注册人权益和责任"页面明确访问或整合到该页面中 (https://www.icann.org/resources/pages/benefits-2013-09-16-en),或采用其他类似设置。

      这应该包括:

      • 鼓励注册人在通过启动 TDRP 将 ICANN 合规部门或第三方牵扯进来前,在注册服务机构层联系注册服务机构来解决争议性转让的相关信息。
      • 针对注册服务机构域名转让政策和转让争议解决政策相关信息的呈现问题对 ICANN 网站采取的改进措施应定期更新(参见上面的 5.2.3.3)。
      • ICANN 网站上到供注册人参考相关信息的链接应表述清楚,并在 ICANN 主页上突出显示。这将有助于改善旨在为注册人提供转让问题相关指导的 ICANN 网站的可见性和内容。
      • ICANN 合规部门应在其 FAQ/帮助页面上明确说明其在哪些情况下可向注册人提供转让争议方面的帮助。这应包括注册人可请求 ICANN 合规部门督促注册服务机构代表该注册人采取行动的情况。
      • 应特别注意提高以下页面的可访问性和用户友好性:

      到这些注册人帮助网站的链接也应突出显示在 internic.net 和 iana.org 网站上,进一步确保注册人可以轻松访问相关信息。

      建议 #13 — 工作组建议,ICANN 授权注册服务机构最好在其网站上突出显示到 ICANN 注册人帮助网站的链接。而且,注册服务机构还应大力鼓励所有分销商也突出显示这类链接。此外,工作组建议向所有 ICANN 授权注册服务机构传达这一信息。

      注册服务机构可以选择将此链接添加到其网站中已包含注册人相关信息(如注册人权利与责任、WHOIS 信息和/或 2013 RAA 第 3.16 节中 ICANN 规定的其他相关链接)的页面上。

      建议 #14 — 工作组建议无需在现有 IRTP 或 TDRP 中新增任何处罚条款。

      建议 #15 — 作为对未来政策制定流程的一项指导,工作组建议应尽可能地避免就某项具体的政策制定处罚规定。相反,所有政策的处罚规定应保持一致,并受 RAA 中适用条款的监管。

      建议 #16 — 工作组建议不要取消 FOA。不过,考虑到 FOA 存在的一些问题(如批量迁移以及注册服务机构和/或分销商的合并),工作组建议 FOA 的适用性不应局限于电子邮件。相应的改进措施可包括:通过短信传送 FOA 或通过交互式网站授权。但是,无论采取什么创新措施,都必须具有审查功能,因为这仍然是 FOA 的主要功能之一。

      工作组指出,这一建议的实施不应受转让是提前发生(某些批量迁移情况)还是实时发生的影响。

      建议 #17 — 工作组建议,在所有 IRTP 建议实施后(包括 IRTP-D 以及 IRTP-C 的余留事项),GNSO 理事会应与 ICANN 工作人员一同成立一个专家组,收集、讨论和分析相关数据,确定这些改进措施是否改善了 IRTP 流程和争议机制,找出可能余留的不足之处。

      在对 12 个月的实施情况进行评估后,如果 GNSO(和 ICANN 工作人员)认为与域名转让相关的情况未得到改善,则工作组建议应对转让流程进行全面的重新评估。此建议的目的在于,创建一份更简单、效用更快、更安全且让注册人更易理解和方便使用的政策。

      一项更进一步的建议是,在这类审核工作组中引入一名安全专家以及,如果需要真正的双因素身份验证,则按照相应的行业标准来实施。

      建议 #18 — 工作组建议,缔约方和 ICANN 应着手收集有助于为将来 IRTP 审核小组提供工作指导的数据和其他相关信息,尤其是与最终报告"观点"(4.2.7.1) 中所列问题有关的数据和信息。

      为了促进相关数据的收集,实施审核小组应与 ICANN 工作人员保持密切联系,确保及时获得所需数据。

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

      在此 PDP 的期间内,展开了与利益相关方的常规咨询。细节可参见意见追踪列表(最终报告附录 B)。

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

      对于最终报告及其建议,社群没有提出任何疑虑。

      董事会审核了哪些重要材料?

      董事会审核了最终报告、GNSO 理事会给董事会的报告,以及公众意见摘要和对这些意见的回应。

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

      建议根据《ICANN 章程》附录 A 中所述的 GNSO 政策制定流程提出,并且已获得 GNSO 理事会的一致支持。如《ICANN 章程》所述,理事会对动议的绝大多数支持(理事会一致投票赞成)会促使董事会必须采纳建议,除非有超过三分之二的董事会成员投票表示该政策并不符合 ICANN 社群或 ICANN 的最佳利益。

      此外,根据 ICANN 合规性的数据,与转让相关的问题是投诉的第二大方面。对 IRTP 的改进除了为注册人和注册服务机构提供明确性和可预见性之外,潜在地减少了投诉的数量。

      是否会对社群产生积极或者消极影响?

      对 IRTP 和 TDRP 的改进除了为注册人和注册服务机构提供明确性和可预见性之外,潜在地减少了投诉的数量。若采纳建议,则需要大幅更改注册服务机构的流程,因此预计实施这些建议需要大量时间和资源,但是为解决政策制定流程中的问题,这些更改被认为是必不可少的。如果建议得以实施,预计可以有效阐明和增强 IRTP 和 TDRP,有利于所有相关方。

      是否会在财务方面对 ICANN(战略计划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      除了上文所述注册服务机构流程中需要的更改,很可能还有与实施政策(例如更新 ICANN 网站)相关的财务影响,但是这些成本预计在相关部门的预算之内。

      是否存在与 DNS 相关的任何安全性、稳定性或弹性问题?

      董事会批准所提建议不会造成任何与 DNS 有关的安全性、稳定性或弹性问题。

    5. 收集新 gTLD 项目度量指标、为关于竞争、消费者信任和选择的未来 AoC 审核提供支持的建议

      鉴于在《义务确认书》(AoC) 中,ICANN 已承诺在新 gTLD 运营一年后,审核研究新 gTLD 项目对竞争、消费者信任和选择的促进力度。

      鉴于 2010 年 12 月 10 日,ICANN 董事会要求一般会员咨询委员会 (ALAC)、政府咨询委员会 (GAC)、通用名称支持组织 (GNSO) 以及国家和地区名称支持组织 (CCNSO) 就域名系统环境下确立竞争、消费者信任和选择的定义、衡量标准以及三年目标提供建议。董事会于 2013 年收到 GNSO 理事会 [PDF, 352 KB] 和 ALAC [PDF, 491 KB] 各自关于具体度量指标的建议。

      鉴于(在第 2013.07.18.05 – 2013.07.18.072013.09.28.13 – 2013.09.28.14号决议中)董事会要求总裁兼首席执行官在成立未来的 AoC 竞争、消费者信任和选择审核小组之前,先成立志愿者小组(竞争、消费者信任和选择实施建议小组 [IAG-CCT]),这有几大目的,包括评估采纳 GNSO 理事会和 ALAC 建议的可行性、效用和成本效益,并上报董事会。

      鉴于 2014 年 10 月 1 日,IAG-CCT 向董事会提交最终报告,就收集数据为竞争、消费者信任和选择审核提供信息提出建议。

      兹此发布第 2015.02.12.07 号决议:ICANN 董事会感谢 IAG-CCT 的辛勤工作,感谢工作组对数据收集提出的建议,这是关于 gTLD 空间竞争、消费者信任和选择的未来审核的重要意见。

      第 2015.02.12.08 号决议:兹指示 ICANN 总裁兼首席执行官或其指定人员立即开始收集与 IAG-CCT 最终报告所建议度量指标相关的数据,并优先处理具有时效性的度量指标,以及已确定有可用数据的度量指标。

      第 2015.02.12.09 号决议:兹指示 ICANN 总裁兼首席执行官或其指定人员在数据可用时为 IAG-CCT 最终报告 [DOCX, 105 KB] 表 4 所列度量指标收集数据,注意这些度量指标已标为可能在以后收集数据,依赖于将来召集的审核小组展开的讨论。

      第 2015.02.12.07 - 2015.02.12.09 号决议的理由

      董事会为什么要解决此问题?

      本决议是董事会之前决议(第2013.07.18.05 - 2013.07.18.07 号第 2013.09.28.13 - 2013.09.28.14 号)的延续,内容有关评估社群提议的度量指标,供将来用于按照《义务确认书》(AoC) 审核新 gTLD 在竞争、消费者信任和选择领域中的影响。本决议还立足于董事会决议(第 2014.03.27.22 - 2014.03.27.26 号),内容有关采纳由消费者调查和经济调查实施咨询小组提出的临时建议。

      正在考虑的提案是什么?

      此董事会决议要求 ICANN 立即开始为 IAG-CCT 建议的度量指标收集数据。此决议通过大部分 IAG 建议,并允许审核小组再次审核关于成本和有用性的一些度量指标,尽管这些指标的数据将在可供使用时收集。

      此工作将立即展开,牵涉到为工作人员收集必要数据分配时间,或从相关第三方(包括 ICANN 的缔约方)购买或另行取得数据。

      董事会审核了哪些重要材料?

      董事会审核的材料有:实施咨询小组 2014 年 10 月 1 日的最终报告 (https://community.icann.org/download/attachments/48349551/IAGCCT%20Final%20report.docx?version=1&modificationDate=1418863127000&api=v2),工作人员提交的简报材料,2014 年 3 月通过的决议(批准为消费者调查和经济调查提供资金),ALAC [PDF, 491 KB] 和 GNSO [PDF, 352 KB] 先前的相关建议书,包括根据 IAG-CCT 当前建议更新后的建议书版本。

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

      董事会认为要为此评估收集的数据对于支持准确审查 gTLD 的引入对竞争、消费者信任和选择起到何等促进作用很重要。ICANN 通过参与这些活动,致力于确保相关数据可供将来的审核小组和更广泛的社群使用,以支持未来根据 AoC 对新 gTLD 项目开展的研究。本决议呼吁开始实施工作是为了方便在时机合适时促进 AoC 审核工作。

      是否会在财务方面对 ICANN(战略计划、运营规划、或预算)产生影响或不良后果?

      实施此决议的资金已纳入 2015 财年预算,也会在规划 2016 财年预算时予以考虑。

      是否存在与 DNS 相关的任何安全性、稳定性或弹性问题?

      本决议对 DNS 的安全性、稳定性或弹性没有影响。

      董事会采取行动前是否需要征询公众意见?

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

    6. 安全与稳定咨询委员会 (SSAC) 成员连任

      鉴于《章程》第 XI 条第 2 款第 2 小节对安全与稳定咨询委员会 (SSAC) 做出了规定。

      鉴于董事会在第 2010.08.05.07 号决议中批准了章程修订,规定 SSAC 成员的任期为三年,要求在任期内分期担任职务,并授权 SSAC 主席推荐当前的所有 SSAC 成员连任整个或部分任期,以实施章程的修订内容。

      鉴于根据第 2010.08.05.08 号决议,董事会任命的 SSAC 成员的任期有 1 年、2 年和 3 年,即于 2011 年 1 月 1 日上任并分别于 2011 年 12 月 31 日、2012 年 12 月 31 日以及 2013 年 12 月 31 日离任。

      鉴于 2014 年 6 月,SSAC 成员资格委员会对任期将于 2014 年 12 月 31 日结束的 SSAC 成员进行了一次年度审核,并向 SSAC 提交了有关成员连任的建议。

      鉴于 2014 年 11 月 24 日,SSAC 成员批准了成员连任。

      鉴于 SSAC 建议董事会再次任命以下 SSAC 成员,任期为 3 年:格雷格•艾伦 (Greg Aaron)、唐•布卢门撒尔 (Don Blumenthal)、K•C•克拉菲 (KC Claffy)、莱曼•查平 (Lyman Chapin)、史蒂夫•克罗克 (Steve Crocker)、马克•科斯特斯 (Mark Kosters)、拉斯•芒迪 (Russ Mundy)、罗德•拉斯穆森 (Rod Rasmussen) 和马克•塞登 (Mark Seiden)。

      兹此发布第 2015.02.12.10 号决议:董事会接受 SSAC 的建议,再次任命以下 SSAC 成员,任期为三年,即于 2015 年 1 月 1 日上任,2017 年 12 月 31 日离任:格雷格•艾伦、唐•布卢门撒尔、K•C•克拉菲、莱曼•查平、史蒂夫•克罗克、马克•科斯特斯、拉斯•芒迪、罗德•拉斯穆森和马克•塞登。

      第 2015.02.12.10 号决议的理由

      SSAC 是一个多样化的群体,其成员具备特定主题的专业知识,使 SSAC 能够履行其章程和使命。SSAC 自成立以来已邀请在技术和安全领域有渊博知识和丰富经验的成员加入其中,他们的知识和经验对互联网名称和地址分配系统的安全性和稳定性至关重要。这些人能为 SSAC 委员会履行其章程、执行其使命提供所需的专业知识和经验。

    7. 任命杰夫•胡森到安全与稳定咨询委员会 (SSAC) 任职

      鉴于安全与稳定咨询委员会 (SSAC) 会不时地审查其成员资格并做出适当调整。

      鉴于 SSAC 成员资格委员会代表 SSAC 要求董事会任命杰夫•胡森到 SSAC 任职。

      兹此发布第 2015.02.12.11 号决议:董事会任命杰夫•胡森到 SSAC 任职。

      第 2015.02.12.11 号决议的理由

      SSAC 是一个多样化的群体,其成员具备特定主题的专业知识,使 SSAC 能够履行其章程和使命。SSAC 自成立以来已邀请在技术和安全领域有渊博知识和丰富经验的成员加入其中,他们的知识和经验对互联网名称和地址分配系统的安全性和稳定性至关重要。

      SSAC 能否作为合格的主体持续运营取决于同意自愿投入时间和精力来执行 SSAC 使命的优秀主题问题专家是否增加。杰夫•胡森会为 SSAC 带来宝贵技能。胡森先生担任 APNIC 的首席科学家。他通常涉及与衡量和网络指标相关的项目。近来他潜心研究:可用未分配 IPv4 地址池的耗竭,采用 IPv6 的相关主题,DNS 衡量,DNSSEC 的应用,以及资源公共密钥基础架构 (RPKI) 的设计和运营稳定性。SSAC 相信他会为本组织作出卓越贡献。

    8. 感谢离任的社群成员

      鉴于 ICANN 要感谢各利益相关方社群成员为 ICANN 流程贡献的大量精力和技能。

      鉴于当社群成员在支持组织和咨询委员会中的任期结束时,ICANN 希望对他们表示感谢,以认可他们所做出的贡献。

      鉴于根服务器系统咨询委员会 (RSSAC) 的以下成员将结束任期:

      • 村井纯博士 (Jun Murai) — RSSAC 创始主席

      兹此发布第 2015.02.12.12 号决议:董事会对村井纯博士在任期内所做的工作深表感谢,并祝愿他未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于安全与稳定咨询委员会 (SSAC) 的以下成员将结束任期:

      • 罗德尼•约菲 (Rodney Joffe) — SSAC 成员
      • 杰森•李雯古 (Jason Livingood) — SSAC 成员
      • 布鲁斯•托金 (Bruce Tonkin) — SSAC 成员
      • 斯蒂法诺•特朗匹 (Stefano Trumpy) — SSAC 成员
      • 保罗•维克西 (Paul Vixie) — SSAC 成员

      兹此发布第 2015.02.12.13 号决议:董事会对罗德尼•约菲、杰森•李雯古、布鲁斯•托金、斯蒂法诺•特朗匹和保罗•维克西在任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于通用名称支持组织 (GNSO) 的以下成员将结束任期:

      • 克里斯蒂娜•罗塞特 (Kristina Rosette) — GNSO 知识产权选区主席

      兹此发布第 2015.02.12.14 号决议:董事会对克里斯蒂娜•罗塞特在任期内所做的工作深表感谢,并祝愿她未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于政府咨询委员会 (GAC) 的以下成员将结束任期:

      • 特拉西•哈克肖 (Tracy Hackshaw) — GAC 副主席
      • 彼得•奈特菲尔德 (Peter Nettlefold) — GAC 副主席

      兹此发布第 2015.02.12.15 号决议:董事会对特拉西•哈克肖和彼得•奈特菲尔德在任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

    9. 感谢第 52 届 ICANN 会议的赞助商

      董事会希望对以下赞助商表示感谢:VeriSign, Inc.、公众利益注册管理机构、Afilias Limited、CentralNic、互联网域名系统北京市工程研究中心 (ZDNS)、Neustar、NCC Group、商标信息交换中心、Uniregistry Corp.、Minds + Machines Group、Iron Mountain, Inc.、ION Magazine、Radix FZC 和 ICANNWIKI、InterConnect Communications Ltd 以及 Sedo GmbH。

      董事会对书记员、口译员、视听团队、技术团队和全体 ICANN 工作人员为会议的顺利进行所付出的努力表示最深的谢意。

      董事会还感谢新加坡费尔蒙特酒店和史丹福瑞士酒店的管理层和工作人员为召开本次会议提供了优良的场所和设施。特别感谢以下人士:

      新加坡旅游局会议主管 Dawn Ng 女士;来福士广场会议中心的会议展销拓展高级销售经理 NG Pei Sze;销售营销执行助理经理 Ng Sok Hia;会议服务经理 Joanne Kaeli Phua。

  2. 主要议程:

    1. 在 gTLD 二级释放双字母代码

      鉴于新通用顶级域注册管理机构协议规定两种释放双字符域名的方法:(1) 如果注册管理运行机构与相关政府和国家/地区域名经理人达成协议,则可释放此类双字符域名;或 (2) 注册管理运行机构在为避免相应国家/地区代码出现混淆而采取相应措施的情况下,也可以提议释放域名,但需获得 ICANN 批准。

      鉴于 2014 年 10 月 16 日,董事会指示工作人员为 ICANN 考量双字符域名的释放请求制定和实施有效程序,当中要考虑 GAC 在 2014 年 10 月 16 日洛杉矶公报 [PDF, 127 KB] 中提出的建议。

      鉴于 ICANN 已发布和实施该流程,从 2014 年 12 月 1 日生效。

      鉴于 2015 年 1 月 26 日,GAC 主席向 ICANN 董事会发去 信件 [PDF, 215 KB],代表作为该流程用户的一些 GAC 成员提出问题。GAC 为解决其问题建议了多个可能的解决方案。

      鉴于 2015 年 2 月 11 日,GAC 在公报 [PDF, 264 KB] 中向董事会提出建议,涉及在 gTLD 二级释放双字母代码。GAC 建议董事会修改当前流程以建立有效通知机制,以便在发起请求时通知相关政府。应充分考虑相关政府的意见。GAC 还建议董事会将评议期延长至 60 天。GAC 网站上将公布倾向于同意所有请求而不需要通知的 GAC 成员列表。

      兹此发布第 2015.02.12.16 号决议:董事会接受 2015 年 2 月 11 日 GAC 公报中提出的在 gTLD 二级释放双字母代码的 GAC 建议。董事会指示总裁兼首席执行官或其指定人员修改 双字符 ASCII 标签释放的授权流程,并立即采取如下行动:

      • 对本流程进行改进,并当请求提出后,通知相关政府。相关政府给出的评论将得到充分考量。
      • 针对新请求所启动的公共评议期将为 60 日。
      • 对于尚未启动或已经结束公共评议期的请求,将延长或重新开放公共评议期,确保每个请求的公共评议期的时长达到 60 日。

      第 2015.02.12.16 号决议的理由

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

      董事会目前接受 GAC 建议的行动是延续 2014 年 10 月 16 日的董事会决议,该决议中,董事会授权总裁兼首席执行官制定并实施一个高效的程序,在考虑 GAC 洛杉矶公报 [PDF, 127 KB] 中所提建议的前提下,释放目前在新 gTLD 注册管理机构协议中要求保留的双字符域名。

      ICANN 制定了双字符 ASCII 标签释放的授权流程来实施董事会决议。2014 年 11 月 12 日,ICANN 发布博文,解释用于释放双字符域名的新流程,并将此文发送 GAC。该流程于 2014 年 12 月 1 日生效。2015 年 1 月 26 日,GAC 主席向 ICANN 董事会发去信件 [PDF, 215 KB],代表作为该流程用户的一些 GAC 成员提出问题。GAC 为解决其提出的流程问题建议了多个可能的解决方案。

      迄今 ICANN 已收到总共 300 多个注册管理机构提出的请求。由于董事会今日的行动,ICANN 将根据流程要求延长或重新开放评议期,使请求的评议期总时长达到 60 日。对于已结束或正完成现要求的 30 天评议期的请求,其评议期将延长或重新开放,使每个请求符合 60 日时长的新要求。例如,已完成 30 日评议期的请求将新开放一个为期 30 日的评议期。评议期已过去 15 天的请求将延长当前评议期 30 日,使总时长达到 60 日。今后的所有请求将同样开放 60 日的评议期。

      在审议要采取的行动时,董事会审核了多个材料,并且还考虑了许多重要因素。董事会在审议中考量的重要材料和因素包括但不限于如下各项:

      对社群的总体影响预计将是积极的,因为它在 gTLD 命名空间中创造了多样化和竞争的新机会,而且尚未发现任何具体的用户混淆风险。董事会行动的实施预计不会对 ICANN、社群或公众产生重大的财务影响。ICANN 注册管理机构服务技术评估专家组在 2006 年 12 月 4 日关于在 .name gTLD 中释放双字符域名提案的报告中认定,双字符二级域名的释放不会构成对安全性和稳定性产生严重负面影响的合理风险。董事会行动既不属于 ICANN 支持组织内部定义的政策流程,也不属于需要征询公众意见的 ICANN 组织管理职能决策。

Published on 12 February 2015


1 在章程问题 C 中,工作组建议取消作为 TDRP 争议解决第一层的注册管理机构。因此,尽管章程问题 A 中有相关说明,但此处不会纳入针对注册管理机构的任何报告要求。

2 参见 ADNDRC 关于 TDRP 裁决的四份报告: http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

3 https://www.icann.org/resources/pages/policy-transfers-2014-07-02-en

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