Skip to main content
Resources

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

本页面还提供其他语种:

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

  1. 达成共识的议程:
    1. 批准董事会会议记录
    2. GNSO 理事会针对联系信息翻译和音译的建议
    3. 续约版《.CAT 注册管理机构协议》
    4. 续约版《.TRAVEL 注册管理机构协议》
    5. 续约版《.PRO 注册管理机构协议》
  2. 主要议程:
    1. 2016 年 6 月 ICANN 会议地点协议
    2. 新 ERP 项目的合同签订和费用支出
    3. 储备基金拨款 - USG IANA 管理权移交成本
    4. 新通用顶级域项目:未来轮次方向
    5. 注册服务机构认证协议的保险要求
    6. GNSO 政策与实施建议
    7. 2016 年提名委员会主席和候任主席任命 - 行政会议

  1. 达成共识的议程:

    1. 批准董事会会议记录

      决议(2015.09.28.01),董事会批准分别于 2015 年 7 月 16 日和 7 月 28 日召开的 ICANN 董事会会议的记录。

    2. GNSO 理事会针对联系信息翻译和音译的建议

      2013 年 6 月 13 日,GNSO 理事会启动了一个针对翻译和音译事宜的政策制定流程 (PDP),旨在解决两个章程问题,请参阅 http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf [PDF,185 KB]。

      该 PDP 遵循章程中所载的规定 PDP 步骤,于 2015 年 6 月 12 日发布了最终报告。

      联系信息翻译和音译工作组 (WG) 针对其第一项建议达成了共识,并针对其余的六项建议达成了完全共识。1

      GNSO 理事会审核并讨论了联系信息翻译和音译工作组提出的建议,随后于 2015 年 6 月 24 日以全票通过的结果采纳了这些建议(请参阅http://gnso.icann.org/en/council/resolutions#20150624-3)。

      GNSO 理事会的投票达到并且超出了对 ICANN 缔约方赋予新职责所要求的投票门槛(即绝大多数);以及

      GNSO 理事会投票表决之后,针对批准的建议启动了公共评议期,然后对收到的意见进行了总结和审核 (https://www.icann.org/public-comments/transliteration-contact-recommendations-2015-06-29-en)。

      决议 (2015.09.28.02),董事会采纳了 GNSO 理事会在最终报告中提出的关于联系信息翻译和音译的政策建议。

      决议 (2015.09.28.03),指示 CEO 或其授权的指定人制定并完成一份有关这些建议的实施计划,并继续就实施工作与 GNSO 实施审核小组和社群进行沟通和协作。

      第 2015.09.28.02 – 2015.09.28.03 号决议的理由

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

      域名系统不断国际化,这意味着将有越来越多的互联网用户并不使用(甚至不熟悉)US ASCII,US ASCII 是一个技术术语,指代英语和很多其他西方欧洲语言中使用的基于拉丁文的文字。

      对于寻找域名注册人信息的用户来说,要使联系信息数据成为对其有用的资源,确保这类数据的准确性和一致性至关重要。该 PDP 工作组考虑了如下重要问题:采用对数据进行翻译和/或音译的方式,还是让注册人用最熟悉的文字提交数据?哪一种方式更能满足上述要求?还要考虑用户对此类数据的需要量,以及大量翻译或音译所需要的成本。

      《翻译和音译 PDP 最终报告》中的第一项建议获得了一致的支持,其余六项建议也达成了完全的共识。该报告也获得了 GNSO 理事会的一致支持。

      根据 ICANN 章程附录 A 中所载的后续步骤,在公共评议期结束后,应由 ICANN 董事会负责审核这些建议。

      目前考虑的提案是什么?

      当前考虑采纳以下政策建议:

      建议 1 工作组认为强制规定对联系信息进行翻译/音译并不可取。如果有任何相关方需要对联系信息进行翻译/音译,可以在 Whois 或其他替代系统系统(例如,注册数据访问协议 (RDAP))之外临时翻译/音译。如果注册服务机构/注册管理机构没有自愿承担翻译/音译工作(请参阅建议 5),则这项工作由提出请求的相关方来承担。

      建议 2 尽管工作组指出 Whois 替代系统应该能够接收非 ASCII 文字形式的联系信息,但他们还是建议其数据字段的存储和显示方式能够允许轻松识别不同数据条目所代表的内容,以及注册域名持有人所使用的语言/文字。

      建议 3 工作组建议允许根据通用顶级域提供商的业务模型来选择注册人提交联系信息时所支持的语言和文字。

      建议 4 工作组建议无论使用哪种语言/文字,都要确保数据字段符合《注册服务机构认证协议》(RAA)、相关共识性政策、附加 WHOIS 信息政策 (AWIP) 及任何其他适用政策中规定的标准。对于所输入的联系信息数据应根据上述政策和协议进行验证,所使用的语言/文字必须容易识别。

      建议 5 工作组建议,如果对联系信息进行转换,如果 Whois 替代系统能够为每个注册域名持有人条目显示多个数据集,这些数据应作为附加字段显示(除了注册人提供的权威本地文字字段之外),并且应将这些字段标记为"已转换"并标注其源语言。

      建议 6 工作组建议任何 Whois 替代系统(例如,RDAP)都可以保持灵活性,以便可以添加使用新文字/语言的联系信息,以及扩展其接收、存储和显示联系信息数据的语言/文字功能。

      建议 7 工作组建议根据需要将这些建议与其他 Whois 修改意见进行协调,并在能够接收、存储和显示非 ASCII 字符的 Whois 替代系统可以运营时,尽快实施和/或落实这些建议。

      关于第二个章程问题的分析结果根据建议 1-7,关于谁来决定由哪一方负责将联系信息翻译或音译为一种常见语言的问题已无实际意义。

      建议 1 附有少数意见,内容如下:工作组成员 Petter Rindforth 根据其所属的知识产权选区 (ICP) 的观点,2 建议要求对所有通用顶级域名 (gTLD) 的联系信息进行翻译和/或音译(转换)。

      尽管他同意在某些情况下使用注册人当地语言的联系信息是主要版本(例如,用于识别正在准备进行当地法律诉讼的注册人),但是还有很多情况需要执行全球 WHOIS 搜索(能够以尽可能一致的方式提供对数据的访问权限)才能让数据注册服务实现其在 DNS 中实现透明和问责的目标。另请参阅 [最终报告] 的 5.1.1 节,其中阐述了工作组用以支持需要对所有通用顶级域名的联系信息进行翻译/音译的论据。

      征询了哪些利益相关方或其他相关方的意见?

      在此 PDP 的生命周期内,尤其是在三次 ICANN 会议期间(ICANN 第 49 届、第 50 届和第 51 届会议),以及初步问题报告初步报告的公共评议期和提交给董事会审议之前,与利益相关方进行了常规协商。

      社群提出了哪些顾虑或问题?

      社群提出的主要顾虑是,多文字/多语言的数据库将会导致透明度降低,因为除拉丁文之外,其他文字对于大多数互联网用户来说可能不太易于理解。还会降低数据的可搜索性。社群还担心存有欺诈意图的注册人可能会以不同的文字/语言作为幌子掩盖其身份信息。

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

      董事会审核了最终报告、GNSO 理事会提交给董事会的建议报告,以及公众意见总结和员工对意见的反馈。

      董事会认为哪些是重要因素?

      这些建议是根据 ICANN 章程附录 A 中所述的以下 GNSO 政策制定流程而制定,并且得到了 GNSO 理事会的一致支持。根据 ICANN 章程的规定,如果理事会的绝大多数成员支持这项动议(理事会投票全体支持),则除非董事会内有超过三分之二的成员投票反对,否则董事会必须采纳这项动议,董理会认为这项政策没有照顾到 ICANN 社群或 ICANN 的最佳利益。此外,继续推进域名系统的国际化是 ICANN 的一个重要工作领域。对于真正的全球化 DNS,这些建议或许将有助于提高联系信息数据的用户友好程度和准确性。

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

      最终报告中指出了一些积极影响,包括(但不限于):

      • 不熟悉 US-ASCII 的注册人将可以使用他们最熟悉的文字注册域名;
      • 注册服务机构无需对数据进行翻译或音译,但他们需要验证数据,无论他们支持哪种文字 - 具体支持的语种将由供需情况而定。
      • 注册费用将不会增加,而如果要求注册服务机构将所有联系信息数据翻译或音译为某种文字3 ,将不可避免地导致将成本转移给注册人;
      • 允许注册人在注册域名时使用他们最熟悉的语言/文字将对数据准确性具有积极影响。

      最终报告中指出了一些负面影响,包括:

      • 要搜索联系信息数据并使用 US-ASCII 运营的注册人可能必须先对这些数据进行翻译或音译,才能联系到注册人(当然,即使强制要求翻译或音译,对于寻找相关信息,但不熟悉 US-ASCII 的注册人而言,也同样需要进行这类翻译或音译)。

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

      对 ICANN 没有财务影响。社群成员和更广泛的公众可能需要承担联系信息专业翻译或音译的费用。然而,如果全面要求翻译或音译每个非 US-ASCII 的联系信息,那么潜在成本将提高。

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

      当前的 WHOIS 协议只能支持 US-ASCII 文字。然而,目前将推行注册数据访问协议 (RDAP) 并将此作为 WHOIS 的替换,该系统与其他文字全面兼容。一旦实施 RDAP,或者出现其他有能力处理非 US-ASCII 文字的替换系统,那么董事会批准所拟订的建议将不会引发任何与 DNS 有关的安全性、稳定性或灵活性相关问题。

    3. 续约版《.CAT 注册管理机构协议》

      ICANN 针对 .CAT 顶级域名的拟定续延《注册管理机构协议》 <https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en> 启动了公共评议期:从 2015 年 5 月 28 日开始,2015 年 7 月 7 日结束 <https://www.icann.org/public-comments/cat-renewal-2015-05-28-en>。

      提议的续约版《.CAT 注册管理机构协议》对协议条款进行了修改,《.CAT 注册管理机构协议》将与《新通用顶级域名注册管理机构协议》的格式保持一致。

      针对所提议续约版《注册管理机构协议》的公众意见论坛于 2015 年 7 月 7 日结束,ICANN 收到了个人和组织/小组所提交的十五 (15) 份意见。已经向董事会提交了公众意见总结和分析。

      续约版《注册管理机构协议》已进行了更新,纳入了关于 WHOIS 的现有条款。

      决议(2015.09.28.04),批准提议的续约版《.CAT 注册管理机构协议》 [PDF,621 KB],将授权总裁兼首席执行官或其指定人采取相应行动,确保完成和执行该协议。

      第 2015.09.28.04 号决议的理由

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

      ICANN 与 Fundació puntCAT(以下简称"注册管理运行机构")于 2005 年 9 月 23 日达成了关于 .CAT 顶级域名运营的《注册管理机构协议》。当前的《.CAT 注册管理机构协议》将于 2015 年 12 月 19 日到期。续约版《注册管理机构协议》提案(以下简称"续约版《注册管理机构协议》"或"协议")已经发布,2015 年 5 月 28 日至 2015 年 7 月 7 日为公共评议期。目前,董事会批准了续约版《注册管理机构协议》,由注册管理运行机构继续运营 .CAT 顶级域名。

      正在考虑的提案是什么?

      董事会批准的续约版《注册管理机构协议》中修改了一些条款,使这项协议的格式与《新通用顶级域注册管理机构协议》相符。修改的内容包括:更新技术规范;要求纳入某些 GAC 保护措施作为公益承诺(根据"公益承诺争议解决流程"予以实施);在达到特定门槛后,需使用签署有 2013 年版《注册服务机构认证协议》的注册服务机构;以及更新注册管理机构费用。

      考虑到 .CAT 顶级域名的具体性质(赞助性通用顶级域),2005 年 9 月 23 日发布的《赞助性通用顶级域注册管理机构协议》中纳入了相关条款。具体来讲就是,规格 12 中已经指出了章程中所述的加泰罗尼亚语言与互联网文化社群相关条款,这个社群符合社群的含义,有资格申请注册。续约版《注册管理机构协议》还反映了以前批准的有关保留名称的内容。

      征询了哪些利益相关方或其他相关方的意见?

      ICANN 针对提议的续约版《.CAT 注册管理机构协议》征询了公众意见,公共评议期为 2015 年 5 月 28 日至 2015 年 7 月 7 日,之后对收到的意见进行了总结和分析。此外,ICANN 还与注册管理运行机构进行了双边协商,希望针对在公共评议期发布的需要包含在续约版《注册管理机构协议》中的一系列条款达成共识。

      社群提出了哪些顾虑或问题?

      十五 (15) 名社群成员参与了公共评议。社群成员在意见中提出了三个主要问题:

      • 将旧通用顶级域转换成《新通用顶级域注册管理机构协议》的形式:ICANN 计划使用新通用顶级域注册管理机构协议作为旧通用顶级域注册管理机构续约协议的基础,有些公众意见表达了对此进程的困惑。这些评议者认为,如果采用这种方式,就相当于将新通用顶级域授权后争议解决程序(例如,商标授权后争议解决程序和公益承诺争议解决流程)和统一快速中止程序 (URS) 转变为实际的共识性政策,而没有遵循 ICANN 章程中所规定的政策制定程序。另一方面,有其他意见表示支持 ICANN 保持注册管理机构协议的一致性,并指出向新的协议形式转换也在许可的双边协商范围内。
      • 如果在没有经过政策制定流程 (PDP) 的情况下,直接在旧通用顶级域的续约协议中纳入统一快速中止程序 (URS) 和商标授权后争议解决程序 (PDDRP):收到的大部分意见都表示反对将 URS 纳入所提议的续约版《.CAT 注册管理机构协议》中,他们认为只有在经过由 ICANN 全部利益相关方社群参与的完整政策制定流程 (PDP) 之后,URS 才能成为一项共识性政策。这些评议者还认为,通过签订合同的流程将 URS 强加给旧通用顶级域是对政策制定流程的人为干预,这是不能接受的。另一方面,有些意见表示支持将 URS 纳入续约版《注册管理机构协议》中,这些意见认为注册管理机构可以超越权利保护的最低要求,无需 PDP

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

      董事会在考量的过程中审核了各种材料,包括但不限于以下材料和文档:

      理事会认为哪些因素很重要?

      董事会认真考虑了收到的续约版《注册管理机构协议》相关公众意见以及意见总结和分析。董事会还考虑了在与 ICANN 进行的双边协商中由注册管理运行机构达成共识的条款。董事会了解某些社群成员对于将 URS 纳入续约版《注册管理机构协议》存在疑虑,但董事会指出,将 URS 纳入续约版《注册管理机构协议》中是根据 ICANN 和注册管理运行机构之间的双边协商结果确定的,在双边协商中注册管理运行机构表示有兴趣根据《新通用顶级域注册管理机构协议》来续订其注册管理机构协议。

      董事会指出,建议实施团队 (IRT) 建议将 URS 作为针对所有新通用顶级域的一种强制性权利保护机制 (RPM) 予以采纳。董事会要求 GNSO 针对以下方面提供意见:某些提议的权利保护机制(包括 URS)是否与 GNSO 提议的关于引入新通用顶级域的政策相一致,是否是达成 GNSO 所述原则和目标的适用且有效的方案。STI 考虑了此问题并得出结论:"所有新通用顶级域都必须使用 URS 作为权利保护机制"。换言之,GNSO 认为 URS 与其现有的任何政策建议都不冲突。

      尽管 URS 是根据此处说明的流程而制定和完善的(包括公众意见审核以及 GNSO 相关讨论),但尚无法作为共识性政策采用。除了在 2012 年新通用顶级域轮次提出申请的新通用顶级域注册人之外,ICANN 无法强制要求任何顶级域注册人使用 URS。

      因此,董事会批准续约版《注册管理机构协议》并不表示要强制要求任何旧通用顶级域采纳 URS,做出这类强制要求是不当之举。对于 .CAT,纳入 URS 是注册管理运行机构与 ICANN 在双边协商后形成的意见。

      此外,董事会还考虑了有关将旧通用顶级域的协议向新形式的注册管理机构协议转换的意见。董事会指出,根据现有的注册管理机构协议,在协议到期时只要满足特定要求,就认定为会续约。续约协议的续约条款需经过协商,以确保条款合理,ICANN 和注册管理运行机构都能接受。董事会批准的续约条款是双边协商的结果,所做的协商符合当前注册管理机构协议的要求,转换为新形式的注册管理机构协议不会违反既有的 GNSO 政策。如下所述,新形式的注册管理机构协议不仅有益于注册人和互联网社群,例如提供公益承诺,还带来了一些运营方面的优势,包括要求使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到应急门槛时,可指定临时性应急注册管理运行机构。

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

      在续约流程中,ICANN 根据当前《.CAT 注册管理机构协议》对注册管理运行机构的近期表现进行了审核。发现注册管理运行机构大体上满足其合同要求。

      董事会批准续约版《注册管理机构协议》也将对技术和运营带来积极影响。根据续约版《注册管理机构协议》,当注册管理机构职能达到任何应急门槛时,注册管理运行机构同意 ICANN 为顶级域注册管理机构指定一个临时应急注册管理运行机构,以降低对域名系统的稳定性和安全性造成的风险。另外,注册管理运行机构将根据新通用顶级域协议条款的要求进行技术配备,这将促使注册管理机构使用统一的自动化流程,从而有助于通用顶级域的运营。续约版《注册管理机构协议》同样在规格 11 中以公益承诺的形式纳入了保护措施。

      这也将为注册服务机构和注册人带来积极影响。向新通用顶级域注册管理机构协议转换将会协调所有的注册管理机构,为终端用户创造一个可预见的环境。同时,提议的续约版《注册管理机构协议》要求注册管理运行机构选用 ICANN 认证的注册服务机构,即签署 2013 年注册服务机构认证协议 (RAA) 的机构,这对注册服务机构和注册人都更有益。

      对权利持有人的保护:新通用顶级域协议允许注册管理运行机构采用更多的权利保护机制来保护权利持有人。

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

      如果 ICANN 批准所提议的《.CAT 注册管理机构续约协议》,并不会带来重大的财务影响。然而,应该注意的是,批准续约版《注册管理机构协议》后,预计注册管理机构年费将从 11.2 万美元降到 5.6 万美元。新形式的注册管理机构协议不仅有益于注册人和互联网社群,例如提供公益承诺,还带来了一些运营方面的优势,包括要求使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到应急门槛时,可指定临时性应急注册管理运行机构。这些优势将抵销所谓的财务影响。

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

      如果 ICANN 批准提议的续约版《.CAT 注册管理机构协议》,预期并不会引起与 DNS 相关的任何安全性、稳定性或灵活性问题。实际上提议的续约版《注册管理机构协议》中包含了相应的条款,旨在确保当 DNS 的稳定性或安全性遭受到特定威胁时,允许快速采取措施。作为 ICANN 组织管理职能的一部分,ICANN 于 2015 年 5 月 28 日发布了续约版《注册管理机构协议》草案以征询公众意见。

    4. 续约版《.TRAVEL 注册管理机构协议》

      ICANN 针对续约版《.TRAVEL 通用顶级域注册管理机构协议》提案 <https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en> 启动了公共评议期,开始日期为 2015 年 5 月 12 日,截止日期为 2015 年 7 月 5 <https://www.icann.org/public-comments/travel-renewal-2015-05-12-en>。

      提议的续约版《.TRAVEL 注册管理机构协议》修改了一些条款,使《.TRAVEL 注册管理机构协议》与《新通用顶级域注册管理机构协议》的形式保持一致。

      针对所提议续约版《注册管理机构协议》的公众意见论坛于 2015 年 7 月 7 日结束,ICANN 收到了个人和组织/小组所提交的十五 (15) 份意见。已经向董事会提交了公众意见总结和分析。

      考虑了公众意见之后,董事会认为无需对提议的续约版《.TRAVEL 注册管理机构协议》进行任何修改。

      决议 (2015.09.28.05),批准提议的续约版《.TRAVEL 注册管理机构协议》[PDF,621 KB],将授权总裁兼首席执行官或其指定人采取相应行动,确保完成和执行该协议。

      第 2015.09.28.05 号决议的理由

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

      ICANN 与 Tralliance Registry Management Company, LLC 公司(以下简称"注册管理机构运营商")于 2005 年 5 月 5 日达成了关于 .TRAVEL 顶级域名运营的《注册管理机构协议》。当前的《.TRAVEL 注册管理机构协议》于 2015 年 10 月 19 日到期。续约版《注册管理机构协议》提案(以下简称"续约版《注册管理机构协议》"或"协议")已经发布,2015 年 5 月 12 日至 2015 年 5 月 7 日为公共评议期。目前,董事会批准了续约版《注册管理机构协议》,由注册管理运行机构继续运营 .CAT 顶级域名。

      正在考虑的提案是什么?

      董事会批准的续约版《注册管理机构协议》中修改了一些条款,使这项协议在形式上与《新通用顶级域注册管理机构协议》相一致。修改的内容包括:更新技术规范;要求纳入某些 GAC 保护措施作为公益承诺(根据"公益承诺争议解决流程"予以实施);在达到特定门槛后,需使用签署有 2013 年版《注册服务机构认证协议》的注册服务机构;以及更新注册管理机构费用。

      考虑到 .TRAVEL 顶级域名的具体性质(赞助性通用顶级域),2005 年 5 月 5 日发布的《赞助性通用顶级域注册管理机构协议》中纳入了相关条款。具体来说,规格 12 体现了章程中的相应条款,概述了符合社群含义并且有资格申请注册域名的旅游行业领域。续约版《注册管理机构协议》还反映了以前批准的有关保留名称的内容。

      征询了哪些利益相关方或其他相关方的意见?

      ICANN 于 2015 年 5 月 12 日至 2015 年 7 月 5 日对提议的《.TRAVEL 注册管理机构续约协议》进行了公众意见征询,之后对收到的意见进行了总结和分析。此外,ICANN 还与注册管理运行机构进行了双边协商,希望针对在公共评议期发布的需要包含在续约版《注册管理机构协议》中的一系列条款达成共识。

      社群提出了哪些顾虑或问题?

      十五 (15) 名社群成员参与了公共评议。社群成员在其意见中提出了两个主要问题。

      • 将旧通用顶级域转换成《新通用顶级域注册管理机构协议》的形式:ICANN 计划使用新通用顶级域注册管理机构协议作为旧通用顶级域注册管理机构续约协议的基础,有些公众意见表达了对此进程的困惑。这些评议者认为,如果采用这种方式,就相当于将新通用顶级域授权后争议解决程序(例如,商标授权后争议解决程序和公益承诺争议解决流程)和统一快速中止程序 (URS) 转变为实际的共识性政策,而没有遵循 ICANN 章程中所规定的政策制定程序。另一方面,有其他意见表示支持 ICANN 保持注册管理机构协议的一致性,并指出向新的协议形式转换也在许可的双边协商范围内。
      • 如果在没有经过政策制定流程 (PDP) 的情况下,直接在旧通用顶级域的续约协议中纳入统一快速中止程序 (URS) 和商标授权后争议解决程序 (PDDRP):收到的大部分意见都表示反对将 URS 纳入所提议的续约版《.TRAVEL 注册管理机构协议》中,他们认为只有在经过由 ICANN 全部利益相关方社群参与的完整政策制定流程 (PDP) 之后,URS 才能成为一项共识性政策。这些评议者还认为,通过签订合同的流程将 URS 强加给旧通用顶级域是对政策制定流程的人为干预,这是不能接受的。另一方面,有些意见表示支持将 URS 纳入续约版《注册管理机构协议》中,这些意见认为注册管理机构可以超越权利保护的最低要求,无需 PDP。

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

      董事会在考量的过程中审核了各种材料,包括但不限于以下材料和文档:

      理事会认为哪些因素很重要?

      董事会认真考虑了收到的续约版《注册管理机构协议》相关公众意见以及意见总结和分析。董事会还考虑了注册管理运行机构经过与 ICANN 进行双边协商而达成共识的条款。董事会了解某些社群成员对于将 URS 纳入续约版《注册管理机构协议》存在疑虑,但董事会指出,将 URS 纳入续约版《注册管理机构协议》中是根据 ICANN 和注册管理运行机构之间的双边协商结果确定的,在双边协商中注册管理运行机构表示有兴趣根据《新通用顶级域注册管理机构协议》来续订其注册管理机构协议。

      董事会指出,建议实施团队 (IRT) 建议将 URS 作为针对所有新通用顶级域的一种强制性权利保护机制 (RPM) 予以采纳。董事会要求 GNSO 针对以下方面提供意见:某些提议的权利保护机制(包括 URS)是否与 GNSO 提议的关于引入新通用顶级域的政策相一致,是否是达成 GNSO 所述原则和目标的适用且有效的方案。STI 考虑了此问题并得出结论:"所有新通用顶级域都必须使用 URS 作为权利保护机制"。换言之,GNSO 认为 URS 与其现有的任何政策建议都不冲突。

      尽管 URS 是根据此处说明的流程而制定和完善的(包括公众意见审核以及 GNSO 相关讨论),但尚无法作为共识性政策采用。除了在 2012 年新通用顶级域轮次提出申请的新通用顶级域注册人之外,ICANN 无法强制要求任何顶级域注册人使用 URS。

      因此,董事会批准续约版《注册管理机构协议》并不表示要强制要求任何旧通用顶级域采纳 URS,做出这类强制要求是不当之举。针对 .TRAVEL 的情况,纳入 URS 是注册管理机构运营商和 ICANN 在双边协商后形成的意见。

      此外,董事会还考虑了有关将旧通用顶级域的协议向新形式的注册管理机构协议转换的意见。董事会指出,根据现有的注册管理机构协议,在协议到期时只要满足特定要求,就认定为会续约。续约协议的续约条款需经过协商,以确保条款合理,ICANN 和注册管理运行机构都能接受。董事会批准的续约条款是双边协商的结果,所做的协商符合当前注册管理机构协议的要求,转换为新形式的注册管理机构协议不会违反既有的 GNSO 政策。如下所述,新形式的注册管理机构协议不仅有益于注册人和互联网社群,例如提供公益承诺,还带来了一些运营方面的优势,包括要求使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到应急门槛时,可指定临时性应急注册管理运行机构。

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

      在续约流程中,ICANN 根据当前《.TRAVEL 注册管理机构协议》对注册管理运行机构的近期表现进行了审核。ICANN 认为注册管理运行机构已经大体上达到了合同的要求。

      董事会批准续约版《注册管理机构协议》也将对技术和运营带来积极影响。根据续约版《注册管理机构协议》,当注册管理机构职能达到任何应急门槛时,注册管理运行机构同意 ICANN 为顶级域注册管理机构指定一个临时应急注册管理运行机构,以降低对域名系统的稳定性和安全性造成的风险。另外,注册管理运行机构将根据新通用顶级域协议条款的要求进行技术配备,这将促使注册管理机构使用统一的自动化流程,从而有助于通用顶级域的运营。续约版《注册管理机构协议》同样在规格 11 中以公益承诺的形式纳入了保护措施。

      这也将为注册服务机构和注册人带来积极影响。向新通用顶级域注册管理机构协议转换将会协调所有的注册管理机构,为终端用户创造一个可预见的环境。同时,提议的续约版《注册管理机构协议》要求注册管理运行机构选用 ICANN 认证的注册服务机构,即签署 2013 年注册服务机构认证协议 (RAA) 的机构,这对注册服务机构和注册人都更有益。

      对权利持有人的保护:新通用顶级域协议允许注册管理运行机构采用更多的权利保护机制来保护权利持有人。

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

      如果 ICANN 批准所提议的《.TRAVEL 注册管理机构续约协议》,并不会带来重大的财务影响。然而,应该注意的是,批准续约版《注册管理机构协议》后,预计注册管理机构年费将从 4.6 万美元降到 2.5 万美元。新形式的注册管理机构协议不仅有益于注册人和互联网社群,例如提供公益承诺,还带来了一些运营方面的优势,包括要求使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到应急门槛时,可指定临时性应急注册管理运行机构。这些优势将抵销所谓的财务影响。

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

      如果 ICANN 批准提议的续约版《.TRAVEL 注册管理机构协议》,预期并不会引起与 DNS 相关的任何安全性、稳定性或灵活性问题。实际上提议的续约版《注册管理机构协议》中包含了相应的条款,旨在确保当 DNS 的稳定性或安全性遭受到特定威胁时,允许快速采取措施。作为 ICANN 组织管理职能的一部分,ICANN 于 2015 年 5 月 12 日发布了续约版《注册管理机构协议》草案以征询公众意见。

    5. 续约版《.PRO 注册管理机构协议》

      ICANN 针对续约版《.PRO 通用顶级域注册管理机构续约协议》提案启动了公共评议期,开始日期为 2015 年 5 月 28 日,截止日期为 2015 年 7 月 7 日)<https://www.icann.org/public-comments/pro-renewal-2015-05-28-en>。<https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>.

      提议的续约版《.PRO 注册管理机构协议》修改了一些条款,使《.PRO 注册管理机构协议》与《新通用顶级域注册管理机构协议》的形式保持一致。

      针对所提议续约版《注册管理机构协议》的公众意见论坛于 2015 年 7 月 7 日结束,ICANN 收到了个人和组织/小组所提交的十四 (14) 份意见。已经向董事会提交了公众意见总结和分析。

      续约版《注册管理机构协议》已进行了更新,纳入了关于三级域注册的现有条款。

      决议 (2015.09.28.06),批准提议的续约版《.PRO 注册管理机构续约协议》[PDF,586 KB],将授权总裁兼首席执行官或其指定人采取相应行动,确保完成和执行该协议。

      第 2015.09.28.06 号决议的理由

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

      ICANN 与 Registry Services Corporation 公司(以下简称"注册管理机构运营商")于 2010 年 4 月 22 日达成了关于 .PRO 顶级域名运营的《注册管理机构协议》。当前的《.PRO 注册管理机构协议》于 2015 年 10 月 20 日到期。续约版《注册管理机构协议》提案(以下简称"续约版《注册管理机构协议》"或"协议")已经发布,2015 年 7 月 28 日至 2015 年 5 月 7 日为公共评议期。目前,董事会批准了续约版《注册管理机构协议》,由注册管理运行机构继续运营 .PRO 顶级域名。

      正在考虑的提案是什么?

      董事会批准的续约版《注册管理机构协议》中修改了一些条款,使这项协议在形式上与《新通用顶级域注册管理机构协议》相一致。修改的内容包括:更新技术规范;要求纳入某些 GAC 保护措施作为公益承诺(根据"公益承诺争议解决流程"予以实施);在达到特定门槛后,需使用签署有 2013 年版《注册服务机构认证协议》的注册服务机构;以及取消了注册管理机构能够向注册服务机构收取的最高价格上限。

      具体来说就是,提议将《.PRO 协议》附录 11 中的现有注册限制替换为适用于所有新通用顶级域的一系列标准公益承诺。然而,提议的续约版《注册管理机构协议》已更新,其中包含了与三级域名注册相关的条款。此外,规格 11 中添加了 GAC 第 1 类的第 1 至第 3 条保护措施。续约版《注册管理机构协议》还取消了注册管理机构能够向注册服务机构收取的域名服务费价格上限,并反映以前批准的有关保留名称的内容。

      征询了哪些利益相关方或其他相关方的意见?

      ICANN 于 2015 年 7 月 28 日至 2015 年 7 月 5 日对提议的《.PRO 注册管理机构续约协议》进行了公众意见征询,之后对收到的意见进行了总结和分析。此外,ICANN 还与注册管理运行机构进行了双边协商,希望针对在公共评议期发布的需要包含在续约版《注册管理机构协议》中的一系列条款达成共识。

      社群提出了哪些顾虑或问题?

      十四 (14) 位社群成员参与了公共评议。社群成员在其意见中提出了两个主要问题。

      • 将旧通用顶级域转换成《新通用顶级域注册管理机构协议》的形式:ICANN 计划使用新通用顶级域注册管理机构协议作为旧通用顶级域注册管理机构续约协议的基础,有些公众意见表达了对此进程的困惑。这些评议者认为,如果采用这种方式,就相当于将新通用顶级域授权后争议解决程序(例如,商标授权后争议解决程序和公益承诺争议解决流程)和统一快速中止程序 (URS) 转变为实际的共识性政策,而没有遵循 ICANN 章程中所规定的政策制定程序。另一方面,有其他意见表示支持 ICANN 保持注册管理机构协议的一致性,并指出向新的协议形式转换也在许可的双边协商范围内。
      • 如果在没有经过政策制定流程 (PDP) 的情况下,直接在旧通用顶级域的续约协议中纳入统一快速中止程序 (URS) 和商标授权后争议解决程序 (PDDRP):收到的大部分意见都表示反对将 URS 纳入所提议的续约版《.PRO 注册管理机构协议》中,他们认为只有在经过由 ICANN 全部利益相关方社群参与的完整政策制定流程 (PDP) 之后,URS 才能成为一项共识性政策。这些评议者还认为,通过签订合同的流程将 URS 强加给旧通用顶级域是对政策制定流程的人为干预,这是不能接受的。另一方面,有些意见表示支持将 URS 纳入续约版《注册管理机构协议》中,这些意见认为注册管理机构可以超越权利保护的最低要求,无需 PDP。

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

      董事会在考量的过程中审核了各种材料,包括但不限于以下材料和文档:

      理事会认为哪些因素很重要?

      董事会认真考虑了收到的续约版《注册管理机构协议》相关公众意见以及意见总结和分析。董事会还考虑了注册管理运行机构经过与 ICANN 进行双边协商而达成共识的条款。董事会了解某些社群成员对于将 URS 纳入续约版《注册管理机构协议》存在疑虑,但董事会指出,将 URS 纳入续约版《注册管理机构协议》中是根据 ICANN 和注册管理运行机构之间的双边协商结果确定的,在双边协商中注册管理运行机构表示有兴趣根据《新通用顶级域注册管理机构协议》来续订其注册管理机构协议。

      董事会指出,建议实施团队 (IRT) 建议将 URS 作为针对所有新通用顶级域的一种强制性权利保护机制 (RPM) 予以采纳。董事会要求 GNSO 针对以下方面提供意见:某些提议的权利保护机制(包括 URS)是否与 GNSO 提议的关于引入新通用顶级域的政策相一致,是否是达成 GNSO 所述原则和目标的适用且有效的方案。STI 考虑了此问题并得出结论:"所有新通用顶级域都必须使用 URS 作为权利保护机制"。换言之,GNSO 认为 URS 与其现有的任何政策建议都不冲突。

      尽管 URS 是根据此处说明的流程而制定和完善的(包括公众意见审核以及 GNSO 相关讨论),但尚无法作为共识性政策采用。除了在 2012 年新通用顶级域轮次提出申请的新通用顶级域注册人之外,ICANN 无法强制要求任何顶级域注册人使用 URS。

      因此,董事会批准续约版《注册管理机构协议》并不表示要强制要求任何旧通用顶级域采纳 URS,做出这类强制要求是不当之举。针对 .PRO 的情况,纳入 URS 是注册管理机构运营商和 ICANN 在双边协商后形成的意见。

      此外,董事会还考虑了有关将旧通用顶级域的协议向新形式的注册管理机构协议转换的意见。董事会指出,根据现有的注册管理机构协议,在协议到期时只要满足特定要求,就认定为会续约。续约协议的续约条款需经过协商,以确保条款合理,ICANN 和注册管理运行机构都能接受。董事会批准的续约条款是双边协商的结果,所做的协商符合当前注册管理机构协议的要求,转换为新形式的注册管理机构协议不会违反既有的 GNSO 政策。如下所述,新形式的注册管理机构协议不仅有益于注册人和互联网社群,例如提供公益承诺,还带来了一些运营方面的优势,包括要求使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到应急门槛时,可指定临时性应急注册管理运行机构。

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

      作为续约流程的一部分,ICANN 依据现有的《.PRO 注册管理机构协议》对注册管理运行机构的近期表现进行了审核。ICANN 认为注册管理运行机构已经大体上达到了合同的要求。

      董事会批准续约版《注册管理机构协议》也将对技术和运营带来积极影响。根据续约版《注册管理机构协议》,当注册管理机构职能达到任何应急门槛时,注册管理运行机构同意 ICANN 为顶级域注册管理机构指定一个应急临时注册管理运行机构,以降低对域名系统的稳定性和安全性造成的风险。另外,注册管理运行机构将根据新通用顶级域协议条款的要求进行技术配备,这将促使注册管理机构使用统一的自动化流程,从而有助于通用顶级域的运营。续约版《注册管理机构协议》同样在规格 11 中以公益承诺的形式纳入了保护措施,包括 GAC 的 1 类保护措施 1-3。

      这也将为注册服务机构和注册人带来积极影响。向新通用顶级域注册管理机构协议转换将会协调所有的注册管理机构,为终端用户创造一个可预见的环境。同时,提议的续约版《注册管理机构协议》要求注册管理运行机构选用 ICANN 认证的注册服务机构,即签署 2013 年注册服务机构认证协议 (RAA) 的机构,这对注册服务机构和注册人都更有益。

      对权利持有人的保护:新通用顶级域协议允许注册管理运行机构采用更多的权利保护机制来保护权利持有人。

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

      如果 ICANN 批准提议的续约版《.PRO 注册管理机构协议》,并不会在财务方面产生较大影响。

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

      如果 ICANN 批准提议的续约版《.PRO 注册管理机构协议》,并不会引起与 DNS 相关的安全、稳定或弹性问题。,实际上提议的续约版《注册管理机构协议》中包含了相应的条款,旨在确保当 DNS 的稳定性或安全性遭受到特定威胁时,允许快速采取措施。作为 ICANN 组织管理职能的一部分,ICANN 于 2015 年 5 月 28 日发布了续约版《注册管理机构协议》草案以征询公众意见。

  2. 主要议程:

    1. 2016 年 6 月 ICANN 会议地点协议

      ICANN 计划在拉丁美洲/加勒比海地区域召开 2016 年的第二次公共会议。

      工作人员就提议的拉丁美洲/加勒比海区域的地点进行了深入审核,认为巴拿马城(巴拿马)是最合适的城市。

      决议 (2015.09.28.07):董事会授权总裁和 CEO 或其指定人参与并协调相关合同签订和费用方面工作,妥善安排针对 2016 年 6 月在巴拿马城(巴拿马)举办 ICANN 公共会议的主办酒店/会议中心签订所有必需的合同,并管理费用支出,总费用不得超过 110 万美元。

      决议 (2015.09.28.08):根据 ICANN 章程第 3 条第 5.2 节的规定,出于协商目的,本决议中的特定决议项属于机密信息,直到总裁和 CEO 决定发布该机密信息。

      第 2015.09.28.07 - 2015.09.28.08 号决议的理由

      根据 ICANN 公共会议的日程安排,目前 ICANN 每年在不同的地理区域(依据 ICANN 章程中的定义)举行三次会议。ICANN 第 56 届会议定于 2016 年 6 月 27 日至 30 日在拉丁美洲/加勒比海区域召开。ICANN 在 2015 年 3 月 23 日发布了针对拉丁美洲/加勒比海区域会议地点的建议征集公告。各类相关方均向 ICANN 提交了提案。

      工作人员对提议的地点及其他地点进行深入分析,并准备了一份文件,指出了符合"会议选择标准"的地点(请参阅 http://meetings.icann.org/location-selection-criteria)。根据提案和分析结果,ICANN 决定将巴拿马城(巴拿马)定为 ICANN 第 56 届会议的举办地。

      董事会审核了工作人员针对在巴拿马城(巴拿马)召开会议所做的简报,认为关于 2016 年 6 月 ICANN 公共会议的提案以及所选设施的相关费用符合"会议选择标准"的关键要素。

      主办会议并提供必要的差旅补助将对 ICANN 产生财务影响,同时也会给承担会议差旅费用的社群带来财务影响。但无论会议地点选在何处,此类影响都无法避免。这项行动不会对 DNS 的安全性或稳定性造成任何影响。

      董事会感谢为 ICANN 第 56 届会议的选址工作提供建议的所有人员。

      此行动属于组织管理职能,无需征询公众意见。

    2. 新 ERP 项目的合同签订和费用支出

      ICANN 确定需要采购一套集成的企业资源计划 (ERP) 解决方案。

      在 2015 年 9 月 11 日的会议上,董事会财务委员会审核了新 ERP 项目的财务影响,然后考虑了另一种替代方案。

      董事会风险委员会的部分成员审核了提议的 ERP 解决方案,并就风险因素和有用的风险缓解措施,向工作人员提供了指导意见。

      工作人员和董事会财务委员会均建议董事会授权总裁和 CEO 或其指定人采取一切必要措施执行新 ERP 项目的合同(在本文件的参考资料中有详细介绍),并按照这些合同支出必要费用。

      决议 (2015.09.28.09):董事会授权总裁和 CEO 或其指定人采取一切必要措施执行新 ERP 解决方案的合同(在本文件的参考资料中有详细介绍),并按照这些合同支出必要费用。

      决议 (2015.09.28.10):根据 ICANN 章程第 3 条第 5.2 节的规定,出于协商目的,本决议中的特定决议项属于机密信息,直到总裁和 CEO 决定发布该机密信息。

      第 2015.09.28.09 - 2015.09.28.10 号决议的理由

      在过去的五年内,ICANN 通过多种形式逐渐壮大规模,其复杂性也随之相应增加,包括但不限于:(i) 工作人员数量增加至原来的 3 倍;(ii) 全球分支扩展为三个运营中心和多个合作中心;(iii) 各种流程的全球化和复杂性程度比以往更高。同时,包括财务、人力资源和采购系统在内的独立后勤部门基础设施为现有组织提供支持,这套基础设施是至少在五年前设计和实施的。采购一套集成的企业资源计划 ERP 解决方案,并在统一的系统中予以实施,这有利于提升系统容量、全球报告和分析能力、工作效率和跨职能效率,增强内部控制,从而加快 ICANN 向卓越运营发展的步伐。

      工作人员深入分析了以下两种可选方案:(i) 改造现有的各个系统,小幅提升系统容量,尽可能开发接口;(ii) 实施集成的 ERP 方案。如果采用改造的方案,在第一年费用较低,但由于实施系统改造后,五年内仍将需要重大升级,那么总费用将大大超过集成 ERP 方案。此外,系统改造仅能小幅提升后勤部门的容量和效率,却需要花费大量资金开发复杂且需要大量维护的接口,最终的容量还远不如集成解决方案。

      因此,我们认为集成的 ERP 解决方案才是更可行、更经济高效的解决方案。

      集成的 ERP 解决方案项目设计如下:

      内部资源:该项目较早就提出了,但一直搁置未实施,直至有经验丰富的高级人员能够加入并且各业务部门(IT、财务、人力资源、采购)参与进来后,该项目才开展到充分的成熟阶段。2014 年加盟的高级 IT 总监以及 2015 年 3 月加盟的财务副总裁在大型系统实施项目方面拥有非常丰富的经验,因此条件已成熟。内部资源包括:

      1. 三个主题专家团队:每个团队包括两个级别的专家(一名带头人和分别负责一种职能的几名专家)
      2. 涵盖设计和实施阶段的四个支持资源可确保正常的日常运营,与此同时,还有充足的专家重点展开 ERP 项目
      3. 一名在 ERP 实施领域拥有丰富经验的专职项目经理(签约)。
      4. 三个 IT 资源:一名高级 IT 总监(监督和管理)、一名 IT 业务分析员和一名 IT 经理(人力资源部门和财务/采购部门各一名)
      5. 指导委员会成员包括:CIIO、COO、CFO 和高级 IT 总监
      6. 一名人力资源变更管理人员(待招聘)
      7. 自项目初期起执行嵌入式企业资源管理 (ERM) 审核。

      外部资源:

      1. 较大型的 ERP 供应商拥有广泛的认证业务合作伙伴资源及内部咨询资源,ICANN 可以充分利用这些资源。
      2. ICANN 将通过个人面试流程来选择最符合条件的技术顾问。

      技术解决方案:软件即服务 (SaaS) 模式:

      1. 可直接配置的 Web 平台,解决方案供应商的所有客户均可使用该平台
      2. 每个客户根据其业务部门的需求灵活配置功能(无需开发软件,无需定制)
      3. 每项功能的标准范围和可选流程均基于流程来设计,可据此控制最佳实践,可直接进行配置。
      4. 该平台将定期进行更新,拥有丰富的新功能路线图,并在平台中向客户免费提供这些新功能。
      5. SaaS 供应商将根据服务水平协议 (SLA) 对系统性能进行监控和管理

      系统安全:

      1. 数据传输:设计了包含多个步骤的数据转换策略,包括测试、调节和验证流程。
        1. ICANN 将转换历史交易数据和所有主文件数据。
        2. 所有转换程序都将经过充分测试以确保其准确性和完整性。
        3. ICANN 将展开部门测试,即两个会议室试点(CRP),主要测试业务流程、系统配置和数据文件转换。
        4. ICANN 将展开业务试点,模拟完整的实际业务流程(例如,从订单到收款和从采购到付款),并测试完整的历史数据和主文件数据转换流程。
      2. 数据安全:RFP 流程包括针对灾难恢复、数据中心运营管理、数据加密、数据日志和 ICANN 专享 ERP 环境的演示。
        1. ICANN 将按世界先进的标准实施数据安全配置,包括在良好的内部控制基础上进行数据加密、访问控制管理、系统日志访问和审核以及访问安全配置。

      此外,董事会审核了工作人员和董事会财务委员会针对新 ERP 解决方案的合同签订和费用支出职权所提出的建议。

      实施新 ERP 解决方案将对 ICANN 造成财务影响。目前在董事会于 2015 年 6 月 25 日批准的 2016 财年运营规划和预算中也指出了这种影响。这项行动不会对域名系统的安全、稳定与弹性造成任何直接影响。

      此行动属于组织管理职能,无需征询公众意见。

    3. 储备基金拨款 - USG IANA 管理权移交费用

      2015 年 4 月 26 日,董事会授权从储备基金中拨款来偿付 2015 财年产生的 USG IANA 管理权移交项目相关费用,总费用不得超过 700 万美元。

      在 2015 财年,ICANN 实际花费 870 万美元,其中包括计划外的独立法律咨询费用,约为 310 万美元。

      董事会重申其在 2015 年 6 月 25 日发布的声明,即董事会"愿尽量支持社群获取其在为移交流程提供建议过程中所需的建议,同时也深知确保以负责、高效方式利用社群委托给 ICANN 的资金非常重要。我们希望确保未来对独立法律顾问的工作继续实施成本控制措施。"(请参阅 https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c)。

      董事会财务委员会建议董事会授权从储备基金中拨款来偿付 2015 财年 USG IANA 管理权移交项目产生的 870 万美元,该建议获得董事会批准。

      决议 (2014.09.28.11):董事会授权总裁和 CEO 或其指定人从储备基金中拨款来偿付 2015 财年 USG IANA 管理权移交项目产生的 870 万美元。

      第 2015.09.28.11 号决议的理由

      USG IANA 管理权移交项目属于大型项目,ICANN 社群整体为此项目付出了大量时间和资源。ICANN 为社群工作提供的支持非常关键,有助于社群成功完成项目(包括 USG IANA 管理权移交提案制定工作和问责制工作)。

      考虑到该项目的特殊性质及预计产生的大量费用,此项目的资金无法通过 ICANN 年度运营收入来承担。因此,董事会在批准 2015 财年运营规划和预算时,已经通过从储备基金中拨出资金相应地提供了该项目费用(700 万美元)的预计资金。

      由于该项目费用是在 2015 财年产生的,董事会批准从储备基金中拨款来偿付在 2015 财年 USG IANA 管理权移交项目产生的相关实际费用,因此董事会批准的 2015 财年运营规划和预算中包含最高 700 万美元的专项拨款。

      由于该项目在 2015 财年产生的总费用为 870 万美元,该费用超过了董事会在第 2015.04.26.17 号决议中授权从储备基金中拨出的 700 万美元,因此 ICANN 正在请求董事会的批准,希望能从储备基金中拨出实际产生的 870 万美元总费用。这项行动不会对域名系统的安全、稳定与弹性造成任何直接影响。

      此行动属于组织管理职能,无需征询公众意见。

    4. 新通用顶级域项目:未来轮次方向

      董事会的第 2012.02.07.05 号决议重申了 ICANN 对尽快启动新通用顶级域项目后续轮次的承诺。

      目前正在展开针对新通用顶级域项目 2012 轮次的审核工作。

      董事会鼓励利益相关方参与自下而上的相关流程,共同审核和规划新通用顶级域项目的未来轮次。

      决议 (2015.09.28.12):董事会指示 ICANN 员工按计划继续展开新通用顶级域项目的审核工作,鼓励利益相关方社群参与并支持稳健且意义重大的审核流程。

      决议 (2015.09.28.13),当审核流程和潜在的 GNSO 政策制定流程进行到后期阶段后,董事会将密切关注社群的工作并考虑关于未来轮次的指导意见。

      Rationale for Resolutions 2015.09.28.12 – 2015.09.28.13

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

      目前开展的大量审核工作和社群活动有利于确定下一轮次的实施时间和方式。社群要求董事会考虑新通用顶级域项目后续轮次的流程和时间表,以便在长期规划、分析和预算方面给予 ICANN 必要的协助,最终使下一轮次的工作得以有效展开。

      考虑了哪些提案?

      董事会正在考虑当前开展的大量审核流程和社群活动达到何种程度以后才能确定新通用顶级域项目下一轮次的实施时间和方式。董事会考虑了三种方案。第一种方案是为针对未来轮次的社群意见征询流程设定目标截止日期,并确定完成审核流程和潜在 PDP 的大致时间表。这并不是说要为任何相关方完成审核或政策制定工作规定严格的截止日期,而是为所有相关方提供一个大致的时间表,以便于各方规划工作。第二种方案是设定一个预期流程,让董事会先通过该流程考虑审核结果,然后再让员工制定实施计划和时间表。第三种方案是推迟确定时间表或下一轮次的前提条件,等到审核流程和/或 PDP 进行到后期阶段后再确定这些因素。

      董事会目前正在采取行动鼓励相关方继续参与并完成当前的审核流程,同时推迟未来轮次的规划工作,直至审核流程进入后期阶段。

      征询了哪些利益相关方或其他相关方的意见?

      自 2014 年 9 月起,ICANN 工作人员发布了关于新通用顶级域项目审核工作的计划草案并收集了相关反馈意见。4 GNSO 的新通用顶级域后续程序讨论组在探讨新通用顶级域项目的政策影响和发展方面发挥了重大作用。虽然 GNSO 并未进行正式协商,但关于在决定下一轮次发展时应考虑什么样流程的问题已经成为工作组经常重点讨论的主题。此外,各类社群利益相关方(例如缔约方、新注册管理运行机构、ISP 和 IP 运营商以及终端用户社群成员)都对下一轮次的时间表发表了各自的意见。

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

      董事会审核了工作计划草案、《义务确认书》(AoC)、根据对工作计划中所述活动的初步预计制定的预计审核完成时间表、GNSO 初步问题报告(2015 年 8 月 31 日)及与此相关的 GNSO 讨论说明、关于承诺尽快启动第二轮次工作和与利益相关方团体展开协商的第 2012.02.07.05 号决议和第 2014.11.17.10 - 2014.11.17.12 号决议,以及针对用于缓解新通用顶级域项目潜在问题的保护措施展开的权利保护机制审核报告。

      董事会认为哪些是重要因素?

      鉴于审核流程的结果尚未可知,并且可能会需要启动 PDP,那么在这样的早期阶段制定启动新通用顶级域项目后续轮次的时间表未免不切实际。大多数利益相关方社群都希望情况更确定后再进入下一阶段,董事会对此表示理解,但仍认为目前阶段的一项重点工作是对当前轮次实施有意义的审核。董事会将在后期再讨论有关未来轮次的时间表和流程。

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

      社群的部分人员可能会因为缺乏明确的时间表或程序而感到诸多不便。但是,董事会的行动旨在拿出足够的时间和精力开展审核流程,对新通用顶级域项目第一轮次的结果进行全面评估。可能有部分选区将其视为对关于当前开展的各种审核和流程如何推动启动第二轮次的问题没有给予回应。但是,这种处理方式能够确保社群之间在创建相关流程步骤过程中就关键领域的待解决问题继续展开对话。如果未用充足的时间进行审核就匆忙进入下一轮次,可能会导致参与下一轮次工作的社群无法从第一轮次的工作中充分吸取教训。此外,如果确定时间表或预期流程,利益相关方社群可能会对第二轮次的实施时间产生不切实际的预期。

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

      部分项目审核需要咨询专业人士的意见,在 2016 财年的预算中已经为这类活动分配了资金。但这份还未计划和/或落实的决议并未对预算产生其他方面的预期影响。

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

      实施此决议不会对 DNS 的安全、稳定与弹性产生直接影响,但应注意的是,DNS 的安全、稳定与弹性是建议研究的领域。

      ICANN 支持组织内部是否存在明确的政策流程或者 ICANN 的组织管理职能决策是否需要征询公众意见?

      这不是一个明确的政策流程,因为新通用顶级域项目第一轮次的结果还有待评估,暂时还未制定确切的政策流程。但是,在审核工作和 PDP 流程完成后可能需要征询公众意见。

    5. 注册服务机构认证协议的保险要求

      ICANN 于 1999 年发布的《注册服务机构认证政策声明》(简称"认证政策")中指出注册服务机构必须持有至少 50 万美元的商业综合责任保险("CGL")单,如果注册服务机构能够证明较低限额仍可为承保范围内的损失提供合理赔偿,也可降低该保单下限。

      《注册服务机构认证协议》要求注册服务机构的承保金额维持在 50 万美元左右(未提及"认证政策"中的下限)。

      ICANN 收到的反馈意见认为,《注册服务机构认证政策声明》的初衷在于,当注册服务机构实施不当的保险覆盖范围内行为并且阻碍了发展中国家/地区注册服务机构市场的发展时,CGL 保险要求能够为注册人提供补救措施,而 RAA 的 CGL 保险要求并未进一步推进这一目标。

      ICANN 于 2014 年 5 月2015 年 1 月就此问题展开了两轮公众意见征询。

      决议 (2015.09.28.14),2009 年和 2013 年的 RAA 废除了 CGL 保险要求,总裁和 CEO 或其指定人应采取必要措施来实施该决议。

      决议 (2015.09.28.15),GNSO 应考虑是否需要依据《注册服务机构认证政策声明》开展有关保险要求变更的政策工作。

      第 2015.09.28.14 - 2015.09.28.15 号决议的理由

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

      2009 年和 2013 年的《注册服务机构认证协议》要求注册服务机构购买最低保单下限至少为 50 万美元的商业综合责任保险。该要求是根据 ICANN 注册服务机构认证政策声明确立的,声明中指出注册服务机构必须持有至少 50 万美元的商业综合责任保险("CGL")单,如果注册服务机构能够证明较低限额仍可为承保范围内的损失提供合理赔偿,也可降低该保单下限。RAA 的要求并未提及"认证政策声明"中所述的关于可降低保单下限的灵活性。

      CGL 保单通常对企业场所发生的人身伤害和财产损害提供理赔,在部分案件中还为广告损失或人身伤害提供理赔。然而,大部分 CGL 保单的承保范围不包括注册服务机构的过错和疏忽。也就是说,当注册服务机构出现过失行为,例如意外删除注册域名、未续订注册域名或放松警惕,致使域名受到劫持时,域名持有人通常无法从保险公司(根据 CGL 政策)获得赔偿。

      该保险要求对某些希望成为 ICANN 认证注册服务机构的实体带来了财务方面的现实挑战。社群提交的意见认为,鉴于在某些地方该保险类型费用过高和/或根本不存在,这项要求有失公平,不利于这类地区的现有和潜在的注册服务机构。

      因此,董事会正计划批准废除 2009 年和 2013 年 RAA 中的现有 CGL 保险要求,因为商业综合责任保险要求似乎并不能促进其政策目标的实现,而且还为潜在的注册服务机构带来了过重的负担。尽管我们征询了大量的公众意见,但没有证据表明 CGL 要求对注册服务机构存在任何有益之处。

      征询了哪些利益相关方或其他相关方的意见?

      ICANN 从潜在的注册服务机构获得的反馈意见表明在其所在区域内很难或不可能购买所要求的保险。ICANN 召开了研讨会探讨此问题,还讨论了关于 2014 年新加坡 ICANN 会议上提到的服务欠缺地区问题。ICANN 与其他保险顾问以及许多现有和潜在的注册服务机构进行了协商。ICANN 于 2014 年 5 月2015 年 1 月就此问题进行了两轮公众意见征询。作为董事会行动的一部分,董事会鼓励 GNSO 研究该问题。

      社群提出了哪些顾虑或问题?

      社群成员已经向 ICANN 报告了相关情况,即现有的保险要求在很多区域内很难或无法达到,尤其是在北美和欧洲以外的区域。有人认为尽管在某些国家/地区可以购买 CGL 保险,但该保险对部分国家/地区来说是不可行的,而且考虑到各区域的市场条件、生活成本和商业风险,50 万美元的保单下限可能过高(因而从商业角度来说并不可行)。此外还有人提出,鉴于 ICANN 在其他区域的制度已经改进,例如实施合规机制和数据托管制度,应该质疑这项要求是否还有存在的必要。一些社群成员建议 ICANN 为新的和现有的注册服务机构提供一份为现有注册服务机构提供服务的知名保险公司名单,这样注册服务机构就可以购买获得 ICANN 认证所需的保险。

      还有些社群成员则警告说,如果废除 CGL 要求,注册服务机构可能面临无保障的状况。

      董事会在做出此决策时考虑了哪些材料?

      在做出此决策时,董事会考虑了两份与此有关的公众意见报告(分别发布于 2014 年 9 月 2 日 [PDF,405 KB] 和 2015 年 4 月 3 日 [PDF,516 KB])以及董事会参考资料。董事会还考虑了注册服务机构认证政策声明以及 2009 年和 2013 年的《注册服务机构认证协议》。

      董事会认为哪些是做出决策的重要因素?

      现有的保险要求并未达到最初的目的,即保护注册人不受注册服务机构错误行为的影响。而且,该要求抑制了世界上服务欠缺地区市场的竞争。由于原有的保险要求属于 ICANN 政策,因此应由 GNSO 来决定替换的要求是否适当。

      此决策在财务方面有什么影响?

      此决策对 ICANN 没有财务影响。对于不支持购买商业综合责任保险的现有和潜在的注册服务机构,废除此要求可降低机构的相应成本。

      此决策对社群有什么影响?

      根据目前为止获得的所有信息来看,董事会批准废除该保险要求不会对注册服务机构、其他利益相关方和全球公众利益产生负面影响。

      此决策将对潜在和现有的注册服务机构产生积极影响,尤其是对于 CGL 保险费用过高或无法购买的区域内的注册服务机构。这种影响主要是财务方面的影响,同时也会促进发达国家/地区和发展中国家/地区市场的积极性,将有更多机构提交注册服务机构认证申请。

      董事会批准废除该保险要求有利于 ICANN 推动注册服务机构在全球环境中的竞争,并且也使 GNSO 可以借此契机来考虑替换的保险要求是否适当。

      对互联网的安全和稳定有什么影响?

      批准该决议并不会对与 DNS 相关的安全、稳定或弹性问题造成任何影响。

    6. GNSO 政策与实施建议

      2013 年 7 月 17 日,GNSO 理事会批准了 GNSO 非 PDP 政策和实施工作组的章程(http://gnso.icann.org/en/council/resolutions#201307),该工作组旨在为 GNSO 理事会提供以下方面的建议:

      • 用以支持 GNSO 政策和实施相关讨论的一系列原则,要考虑现有 GNSO 运营规程。
      • 用以制定通用顶级域政策的流程,例如以"政策指导"形式提供的流程,包括提供相应的标准以便于评估何时适合采用此流程(制定政策,而不是达成"共识性政策"),而非 GNSO 政策制定流程。
      • 用于展开 GNSO 政策建议实施方面讨论的框架。
      • 用于判断行动性质的标准:可确定什么样的行动事项应该通过政策流程来处理,什么样的行动事项属于实施事宜。
      • 针对 GNSO 实施审核小组(如《PDP 手册》中所定义)的预期职能与运作方式的进一步指导意见。

      2015 年 1 月 19 日,GNSO 政策和实施工作组发布了《初步建议报告》以征询公众意见(请参阅 https://www.icann.org/public-comments/policy-implementation-2015-01-19-en)。

      GNSO 政策和实施工作组审核了收到的意见(请参阅公众意见审核工具 [DOC,267 KB]),并根据这些意见将报告更新为《最终建议报告》,该报告已于 2015 年 6 月 2 日提交到 GNSO 理事会。

      2015 年 6 月 24 日,GNSO 理事会一致通过了《最终意见报告》(请参阅http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF,1.53 MB])。

      2015 年 7 月 28 日,ICANN 董事会指示 ICANN 工作人员发布根据《最终建议报告》中所提的建议提议对 ICANN 章程做出的变更,以征询公众意见(请参阅 https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en)。

      收到了两份支持所提议建议的意见,其中包括一份来自 ALAC 的意见声明。

      ATRT2 建议"董事会应继续支持跨社群交流,以使社群了解政策制定与政策实施的区别。制定互补机制,以便支持组织和咨询委员会 (SO/AC) 与董事会协商问题,包括但不限于董事会决策所涉及的政策、实施和管理问题"(建议 4)。

      决议 (2015.09.28.16),董事会批准在公众意见征询中发布的对 ICANN 章程第 10 条第 3 至 9 款的修订,此修订旨在解决有关 GNSO 指导流程 (GGP) 和 GNSO 快速政策制定流程 (EPDP) 中新 GNSO 投票表决门槛的问题。

      决议 (2015.09.28.17),董事会批准在公众意见征询中发布的对 ICANN 章程附录 A 的修订(请参阅 https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF,656 KB]),即创建概述 GNSO EPDP 的新附录 A-1。

      决议 (2015.09.28.18),董事会批准在公众意见征询中发布的对 ICANN 章程附录 A 的修订(请参阅 https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF,656 KB]),即创建概述 GNSO GGP 的新附录 A-2。

      决议 (2015.09.28.19),董事会批准《最终建议报告》第 4 部分所概述的与政策和实施相关的一系列 GNSO 原则/要求,并指示总裁、CEO 或其指定人以及 ICANN 社群在处理与 GNSO 政策和实施相关的问题时考虑这些原则和要求。

      决议 (2015.09.28.20),董事会批准《最终建议报告》附录 L 中概述的实施审核小组指南和原则,并指示 ICANN 员工和 ICANN 社群在处理与实施相关的问题时考虑这些原则和要求。

      决议 (2015.09.28.21),董事会同意 ALAC 提供的意见并承诺密切监督 GNSO 的政策制定活动,以确保用户和公众利益得到适当考量,复杂政策的实施工作能够在合理的时间范围内完成。

      决议 (2015.09.28.22),董事会指示总裁和 CEO 或其指定人将相关文件发布到 GNSO 和 ICANN 网站的 GNSO 政策和实施相关页面上,以适当征询有关文件的改进意见及其他支持材料。

      决议 (2015.09.28.23),董事会考虑到 ATRT2 建议 4 已完成,因此邀请 ATRT3 根据 ATRT2 的工作结果和建议来审核这些已采纳的建议。

      决议 (2015.09.28.24),董事会感谢 GNSO 社群和其他相关方为此做出的努力。

      第 2015.09.28.16 - 2015.09.28.24 号决议的理由

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

      在讨论新通用顶级域 (gTLD) 项目的实施相关事宜过程中,人们越来越关注哪些话题与政策相关,哪些话题与实施工作相关,具体包括:应当使用哪些流程,且在实施流程中如果出现了不同意见,应当在何时以何种方式采取行动。经过多次讨论,包括发布员工讨论文件,以及在 ICANN 第 46 届会议期间召开了一场社群会议,通用名称支持组织 (GNSO) 理事会于 2013 年 7 月决定建立一个工作组 (WG),由其负责针对以下方面制定一系列建议:

      • 用以支持未来 GNSO 政策和实施相关讨论的一系列原则,要考虑现有 GNSO 运营规程。
      • 用以制定通用顶级域政策的流程,例如以"政策指导"形式提供的流程,包括提供相应的标准以便于评估何时适合采用此流程(制定政策,而不是达成"共识性政策"),而非 GNSO 政策制定流程;
      • 用于展开 GNSO 政策建议实施方面讨论的框架;
      • 用于判断行动性质的标准:可确定什么样的行动事项应该通过政策流程来处理,什么样的行动事项属于实施事宜。
      • 针对 GNSO 实施审核小组(如《PDP 手册》中所定义)的预期职能与运作方式的进一步指导意见。

      2015 年 6 月 24 日,GNSO 理事会一致通过了工作组的建议,随后将其提交给 ICANN 董事会审议。

      此外,问责制和透明度审核小组 2 (ATRT2) 认为此问题是需要优先处理的事项。"董事会应继续支持跨社群交流,以使社群了解政策制定与政策实施的区别。制定互补机制,以便支持组织和咨询委员会 (SO/AC) 与董事会协商问题,包括但不限于董事会决策所涉及的政策、实施和管理问题"(建议 4)。

      目前考虑的提案是什么?

      董事会目前的行动是采纳 GNSO 针对政策和实施所提的建议。采纳的建议包括三个新的 GNSO 流程,其中 GNSO 指导流程 (GGP) 和 GNSO 快速政策制定流程 (EPDP) 要求变更 ICANN 章程。董事会批准需要对章程做出的变更,以支持 GNSO 指导流程和 GNSO 快速政策制定流程的实施。这些新流程旨在让 GNSO 理事会在符合特定条件情况下可以通过正式的流程,更灵活地处理政策问题。此外,董事会批准提议的 GNSO 政策和实施原则及指南,以便为社群开展 GNSO 政策和实施方面的工作提供进一步指导。

      征询了哪些利益相关方或其他相关方的意见?

      经过多次讨论以后,包括发布了员工讨论文件(请参阅 https://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf [PDF,195 KB] 和 http://forum.icann.org/lists/comments-policy-implementation-31jan13/),以及在 ICANN 第 46 届会议期间举行社群会议(请参阅 http://beijing46.icann.org/node/37133),通用名称支持组织 (GNSO) 理事会于 2013 年 7 月与其他 SO/AC 协商决定(请参阅 http://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf [PDF,236 KB])建立一个 GNSO 工作组,由该工作组处理与 GNSO 政策和实施相关的一系列特定问题。GNSO 工作组在初期就面向所有 ICANN SO/AC 以及 GNSO SG/C 征询了初步意见(请参阅 https://community.icann.org/x/iSmfAg)。在发布初步报告的同时召开公众意见论坛(请参阅 https://www.icann.org/public-comments/policy-implementation-2015-01-19-en),并在 ICANN 第 52 届会议期间召开社群会议(请参阅 https://singapore52.icann.org/en/schedule/wed-policy-implementation)。工作组审核并处理了收到的所有意见,可在公众意见审核工具中查看这些意见(请参阅 https://community.icann.org/x/iSmfAg)。GNSO 理事会一致通过了《最终建议报告》,随后 ICANN 董事会指示 ICANN 工作人员发布提议的 ICANN 章程变更,以征询公众意见(请参阅 https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en)。收到了两份支持所提议建议的意见,其中包括一份来自 ALAC 的意见声明。(请参阅 http://forum.icann.org/lists/comments-bylaws-amendments-31jul15/)。

      社群提出了哪些顾虑或问题?

      工作组审核并处理了收到的所有意见,可在公众意见审核工具中查看这些意见(请参阅 https://community.icann.org/x/iSmfAg)。ALAC 对 ICANN 董事会启动的公众意见论坛做出了回应,在其意见声明中表示赞成此建议,同时建议 ICANN 董事会密切监督 GNSO 的政策制定活动,以确保用户和公众利益得到适当考量,复杂政策的实施工作能够在合理的时间范围内完成。

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

      董事会审核了 GNSO 的《政策和实施最终建议报告》(请参阅 http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF,1.53 MB])及相关材料。

      董事会认为哪些是重要因素?是否会对社群产生积极影响或消极影响?

      董事会认为以下两点极为重要:这些建议是由社群和 ICANN 员工协商制定的,这些建议获得了 GNSO 理事会的一致通过。此外,董事会和 ATRT2 的意见相同,也认为解决该问题十分重要,这些建议使 GNSO 理事会可以通过正式的流程,更灵活地处理政策问题,还为与 GNSO 政策和实施相关的问题提供了必要的说明和可预见性。

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

      实施这些建议不会产生财务影响或不良后果。

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

      目前来看这些建议不会引起与 DNS 相关的安全、稳定或弹性问题。

    7. 2016 年提名委员会主席和候任主席任命 - 行政会议

      BGC 审核了 2016 年提名委员会 (NomCom) 主席和候任主席候选人意向书,考量了针对 2015 年 NomCom 领导层进行的全面评估结果并对候选人进行了面试。

      BGC 建议任命 Stéphane Van Gelder 为 2016 年 NomCom 主席,任命 Hans Petter Holen 为 2016 年 NomCom 侯任主席。

      决议 (2015.09.28.25),董事会任命 Stéphane Van Gelder 为 2016 年 NomCom 主席,任命 Hans Petter Holen 为 2016 年 NomCom 侯任主席。

      第 2015.09.28.25 号决议的理由

      ICANN 章程要求董事会任命提名委员会 (NomCom) 主席和 NomCom 侯任主席。请参阅第 7 条第 2.1 款和 2.2 款,网址为 http://www.icann.org/en/general/bylaws.htm - VII。董事会已委任董事会治理委员会负责推荐 NomCom 主席和候任主席,然后提交给董事会审批。请参阅 BGC 章程,网址为 http://www.icann.org/en/committees/board-governance/charter.htm。(请参阅 https://www.icann.org/news/announcement-2-2015-06-04-en)。(EOI 的提交截止日期已延期至 2015 年 7 月 20 日,请参阅 https://www.icann.org/news/announcement-2015-07-01-en)。BGC 审核了收到的多份 EOI,考察了针对 2015 年 NomCom 领导层进行的全面评估并在提出建议前对候选人进行了面试。董事会考虑并通过了 BGC 针对 2016 年 NomCom 主席和候任主席所提供的建议。此外,董事会感谢所有有意向加盟 2016 年 NomCom 领导层的同事。

      通过公开的 EOI 流程来任命 NomCom 主席和候任主席有利于听取公众意见,并对 ICANN 的透明度和问责制产生积极影响。采纳 BGC 的建议不会对 ICANN 产生财务影响,也不会对域名系统的安全、稳定与弹性造成负面影响。


1 有关共识程度的定义,请参阅 http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf [PDF,344 KB](第 8 页)。

2 另请参阅 5.1.1 和公众意见审核工具(最终报告附录 B)。

3 尽管有人倡议采用其他文字也不无道理,多数人还是认为应采用英语的 US-ASCII。

4 请参阅 https://www.icann.org/news/announcement-3-2014-09-22-en

resolutions-28sep15-zh.pdf  [435 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."