Skip to main content
Resources

理事会决议批准 | ICANN 理事会特别会议

本页面还提供其他语种:

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

*说明:理事会行动理由草案会在相关决议下提供。理由草案只有在理事会会议记录中予以批准后才会成为最终版本。

  1. 认可议程
  2. 批准"CEO 猎聘委员会"成员资格

 

  1. 认可议程

    决议:批准本认可议程中的以下决议:

    1.1. 批准 2011 年 8 月 25 日的 ICANN 理事会会议记录

    第 2011.10.11.01 号决议:理事会批准 2011 年 8 月25 日的理事会会议记要。

    1.2. 批准 2011 年 9 月 17 日的 ICANN 理事会会议记录

    第 2011.10.11.02 号决议:理事会批准 2011 年 9 月17 日的理事会会议记要。

    1.3. 批准授权 .CW (Curacao);对 Netherlands Antilles (.AN) 的过渡性安排

    CW 是分配给库拉索岛的 ISO 3166-1 双字母国家或地区代码。

    ICANN 收到了将 .CW 授权给荷属安的列斯大学 (University of the Netherlands Antilles) 的申请;

    ICANN 已审查了该请求,并认为提议的重新授权符合当地及全球互联网群体的利益;

    第 2011.10.11.03 号决议:批准将上述 .CW 顶级域授权给荷属安的列斯大学 (University of the Netherlands Antilles) 的提案。

    .AN 顶级域之前是分给荷属安的列斯的 ISO 3166-1 双字母国家或地区代码,这也是授权此域的基础;

    ISO 3166-1 标准已取消 "AN" 代码,而且 ISO 3166 维护机构也建议停止使用该代码;

    ICANN 不对判定国家或地区的定义负责,并且遵守 ISO 3166-1 标准对于何时添加、修改或撤销国家或地区顶级域的相关指导;

    .AN 顶级域仍是组成前荷属安的列斯岛的国家和自治区中各方所使用的主要域;

    此处的过渡计划旨在将相关注册自 .AN 域迁至新域 .CW 和 .SX,但荷属安的列斯大学仍继续管理 .AN 域,直至过渡完成。

    第 2011.10.11.04 号决议:荷属安的列斯大学将根据一系列相关标准,每隔六个月按指示向 ICANN 报告其停运 .AN 域的进程。

    第 2011.10.11.05 号决议:荷属安的列斯大学负责完成 .AN 域过渡至 .CW 域、.SX 域以及任何其他相关域的工作,以帮助其最晚在 2014 年 10 月 31 日前退出 DNS 根区域。

    第 2011.10.11.06 号决议:.AN 域将在 2014 年 10 月 31 日退出 DNS 根区域,除非该域的管理者及早提出相关请求。

    第 2011.10.11.03 – 2011.10.11.06 号决议的理由

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

    如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,且有理由获理事会批准,则他们会将其申请提交给理事会审批。根据ICANN 对及时处理有关IANA 职能(尤其是DNS 根区域)请求的承诺,理事会将力争在下次安排的特别会议上评估此类请求。

    .AN 域过渡至其继任域的时间表安排正与 .CW 及 .SX 域的授权评估工作同时进行。此举是为了使涉及此过渡时间表的机构社群清楚了解相关工作内容。这将有助于机构群体为此过渡工作做好相应准备。

    正在考虑的提案是什么?

    该提案旨在批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。根据现行惯例,理事会将参与决策以继续处理此类请求,作为这个多步骤流程的其中一步。

    该提案还讨论了在恰当的过渡期后,提议将 .AN 域撤出服务的计划。此过渡期能方便当前注册人将其服务迁至相应的新域。

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

    在评估授权申请过程中,工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关方。根据ICANN 对未完成的根区域更改请求保密的惯例,尚未对此问题进行公开咨询。

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

    公布此行动时,所有疑虑或问题也将出现在公开报告中。如果根区域更改请求成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会做出决定后的 1 到 2 个月。

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

    理事会依据各类公众利益标准评估请求。此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保地方互联网群体支持提议的管理者;确保提议的运营商有足够的运营和技术能力;确保提议的管理者以地方为基础并受地方法律约束;确保提议的管理者公平公正地运营;确保在发生运营移交时有适当的计划来保持域的持续稳定性;以及确保行动遵守任何适用的地方法律和法规。工作人员在处理请求期间会要求申请人提供各种材料以支持上述各方面内容。从这些支持材料和其他工作人员研究中得出的相关信息将提供给理事会,并在获批请求实施结束时在公开报告中发布。

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

    理事会将讨论公开报告中与国家或地区代码域授权基本原则相关的因素,这些内容早前已经介绍过。

    会对机构群体产生积极还是消极影响?

    及时批准符合各类公共利益标准的国家或地区代码域名管理者,对 ICANN 的整体使命和国家或地区代码顶级域服务的地方机构群体均有积极意义。

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

    管理DNS 根区域中的国家或地区代码授权是IANA 的职责,授权行动则不会对预算好的开支有任何重大影响。评估国家或地区代码顶级域内部运营在国内所产生的财政影响并不是ICANN 的职责。ICANN 仅负责确保运营商以国家或地区为基础,并拥有适当的机制以便地方互联网群体正确监督域的持续运营。

    是否存在任何有关 DNS 的安全性、稳定性或灵活性问题?

    对于国家或地区代码顶级域授权,ICANN 力求只批准以下类型的请求:已圆满地解决了相关疑虑;提议的新管理者已充分展示出高水平的运营和技术能力,使这些疑虑降至最低。

  2. 批准 "CEO 猎聘委员会" 成员资格

    2011 年 8 月 16 日,Rod Beckstrom 宣布他将在出任 ICANN 主席和首席执行官 (CEO) 期间继续履责,其任期至 2012 年 1 月。

    ICANN 理事会在 2011 年 9 月 17 日的理事会会议上讨论了 CEO 继任的相关计划。

    ICANN 理事会指示理事会监管委员会向其推荐若干理事会成员,以组成 CEO 猎聘流程管理工作委员会。而理事会将在下次会议中讨论相关候选成员。

    当前理事会的全部成员和联络人(包括即将上任的工作人员)已无保留地声明,他们不会竞选 CEO 之职,亦不会接受任命。

    第 2011.10.11.07 号决议:当前或即将上任的理事会成员或联络人不得作为候选人在现有的 CEO 选举流程中竞聘 CEO 一职。

    以下是由理事会监管委员会推荐、经过理事会挑选而确定的提名名单:

    Steve Crocker

    George Sadowsky

    Bertrand de La Chapelle

    Erika Mann

    Chris Disspain

    Cherine Chalaby

    Ray Plzak

    R. Ramaraj

    第 2011.10.11.08 号决议:理事会批准经推荐的 CEO 猎聘流程管理工作委员会的成员资格。

    第 2011.10.11.09 号决议:George Sadowsky 将出任 CEO 猎聘委员会主席。

    第 2011.10.11.07 – 2011.10.11.09 号决议的理由

    ICANN 理事会已经开始计划并制定用以协助领导换届工作的 CEO 继任流程。该工作委员会的建立有助于理事会将协调流程、定期向理事会报告以及审核机构群体参与流程资格的工作结合为一体,相互配合。及时继任 ICANN CEO 职位有利于本组织继续监管 DNS 安全性与稳定性的相关工作。虽然流程后期很可能需要相关资源支持,但该工作委员会的建立对 ICANN 并无财务上的影响。

resolutions-11oct11-zh.pdf  [187 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."