Skip to main content
Resources

批准的董事会决议 | ICANN 董事会特别会议

本页面还提供其他语种:

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

  1. 主要议程:
    1. IANA 知识产权协议
  1. 主要议程:

    1. IANA 知识产权协议

      鉴于 IANA 管理权移交协调小组 (ICG) 在提案中纳入以下内容:ICANN 所持有的、与执行 IANA 职能相关的知识产权应转让给中立第三方,以便令全球互联网社群受益,并向 ICANN 授予使用权。

      鉴于,所讨论的知识产权包括三个与 IANA 相关的商标和一组 ICANN 注册的域名,这些域名目前正用于执行 IANA 职能或使用与 IANA 相关的商标(统称 IANA IPR)。

      鉴于 2015 年 8 月 15 日,ICANN 董事会发布了一份声明,其中指出,ICANN 准备按照当时社群讨论的意见转让 IANA IPR,并且在 ICANN 作为 IANA 职能运营商期间,对 iana.org 拥有运营控制权。

      鉴于,作为 IANA 职能服务对象的三个运营社群(通过 IETF 接受服务的协议参数社群;通过 RIR 的号码资源社群和通过管理权 CWG 的域名社群)一致同意 IANA IPR 转让给 IETF 基金,而且同意与 IETF 基金合作起草一系列协议来指导 IANA IPR 的转让、授权和持有等相关工作。

      鉴于,一系列协议包括:运营社群与 IETF 基金之间的社群协议、ICANN 与 IETF 基金之间的转让协议,以及 IETF 基金与 ICANN 之间的许可协议。其中,社群协议详述了 IETF 基金将如何与社群合作确保 IANA IPR 能令全球互联网社群受益;转让协议中规定将 IANA IPR 转让给 IETF 基金;而许可协议规定了 IANA IPR 的使用要求,它与这三个运营社群均相关。

      鉴于,这些协议待 NTIA 与 ICANN 之间的 IANA 职能合同到期后才会生效。

      鉴于,一套初步协议草案出炉后,ICANN 应邀加入了社群讨论。ICANN 与 IETF 基金和运营社群合作,对协议做了语言方面的修改。

      鉴于这些协议已于 2016 年 8 月 12 日至 9 月 12 日期间在 ICG 网页上公示,开展了为期 30 天的公共评议期。期间收到了七份意见。这些意见均未要求对协议进行任何修改。公共评议期期间,ICANN 与 IETF 基金和运营社群继续开展对话,完善了这些文件并完成最终修改工作。

      鉴于 ICANN 充分理解其将签署的转让协议和许可协议将会以文件的形式提交董事会,虽然这些协议仍需要进行少量修改。

      鉴于,IANA 管理权移交域名职能跨社群工作组(管理权 CWG)负责实施提案中与域名社群相关的内容,它已向 ICANN 发函请求 ICANN 担任域名社群的社群协议的签署人。管理权 CWG 确认了其希望 ICANN 在承担这一职责时同意遵循的一系列指示。

      鉴于 ICANN 了解这些指示已获得许可,来自管理权跨社群工作组五大章程组织中的四个组织的指示函中包含了这些指示。

      兹此发布第 2016.09.30.01 号决议:ICANN 董事会批准 ICANN 签署其与 IETF 基金之间的、关于转让 IANA IPR 的转让协议。

      兹此发布第 2016.09.30.02 号决议:ICANN 董事会批准 ICANN 签署必要的许可协议,以便在执行各种 IANA 职能过程中使用 IANA IPR。

      兹此发布第 2016.09.30.03 号决议:由于管理权 CWG 五大章程组织中的四个组织(ALAC、ccNSO, GNSO 和 SSAC)所收到的指示函获得了许可,ICANN 董事会批准 ICANN 应管理权 CWG 请求担任社群协议的签署人。此外,这是与 ICG 提案相符的实施项目,而 GAC 曾发表声明表示不反对此 ICG 提案。五大章程组织皆表示同意或不反对,所以董事会确认其将在法律允许的最大范围内接受域名社群任命代表加入 IANA 社群协调小组 (CCG),并将听取 CCG 代表的意见,在适当情况下与 IETF 和其他运营社群开展合作。

      兹此发布第 2016.09.30.04 号决议:ICANN 董事会授权总裁兼首席执行官或其指定人员采取所有必要措施,贯彻落实上述协议。

      第 2016.09.30.01 – 2016.09.30.04 号决议的理由

      ICANN 社群在移交提案中规定,IANA IPR 应由独立于 IANA 职能运营商的实体持有。由于 ICANN 将继续担任 IANA 职能运营商,所以社群确定由 IETF 基金持有 IANA IPR,作为一个弗吉尼亚州普通法基金,IETF 基金属于独立第三方,这对全球互联网社群有利。在今天采取此项行动,以支持和实施提案的这一部分。

      董事会所考量的协议与社群提出的要求以及 2015 年 8 月 15 日提出的董事会意见相一致。协议内容如下:(i) 将原由 ICANN 持有的 IANA IPR 转让给 IETF 基金;(2) 向 ICANN 授予 IANA IPR 使用权,包括 ICANN 将保留对相关域名注册的运营控制权;(3) 针对作为 IANA IPR 持有人的 IETF Trust 应如何确保考虑运营社群所提出的问题,确定相关期望。在预计转让日期之前,IETF 基金无法考虑针对其信托文件的任何修改内容,而这些修改内容能确保运营社群更明确地参与 IANA IPR 的管理。因此,社群协议规定了相关期望,并要求 IETF 基金承诺会考量针对其信托文件的修改内容,解决这种问题以及潜在的破产或强制性转让问题。

      针对这次转让,还有一些财务问题需要考量。首先,这属于 ICANN 资产转让。但是,由于 ICANN 目前持有 IANA IPR 属于公益性质,所以,ICANN 转让的是不具备任何市场价值的资产。此外,按照社群的期望,即 IANA IPR 继续保持公益性质,ICANN 将无偿向 IETF 转让 IPR。协议中也写道,ICANN 可能会遭遇一些财务风险。首先,目前 ICANN 正在针对 IANA 商标使用问题对两个实体实施非正式执行措施。ICANN 已同意自行出资继续实施这些执行措施。ICANN 还同意,如果 IETF 基金因采用与 ICANN 当前相同的做法使用商标而构成侵权,ICANN 会确保其免于承担相关责任。最后,ICANN 承认,其有机会与 IETF 基金合作启动新的执行措施,以实施基金愿意让 ICANN 进行控制的执行措施。鉴于 IANA 商标相关执行措施的使用频率低,这些义务不大可能意味着巨大的财政义务。

      董事会了解,所有管理权 CWG 章程组织均表示同意(ALAC、ccNSO、GNSO 和 SSAC)或不反对(GAC)指示函。因此,ICANN 愿意担任社群协议的签署人。ICANN 在法律允许的最大范围内接受域名社群确定的 IANA 社群协调小组代表。如果社群协议确定 CCG 代表可作为与 IETF 基金或其他运营社群进行协商的实体,ICANN 将听取域名社群所确定的 CCG 代表的意见。根据指示函预计,ICANN 不会提前同意按照 CCG 代表的指示采取任何以下相关措施:导致 ICANN 违反社群协议或许可协议或者导致 ICANN 承担责任的措施。

      此项行动不会对互联网 DNS 的安全性、稳定性或灵活性产生任何影响。签署转让协议和许可协议属于组织管理职能,这类职能已收到公众意见。签署社群协议也属于组织管理职能,而该职能有待征询更多社群意见。

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