Skip to main content
Resources

会议记录 | ICANN 董事会例行会议

本页面还提供其他语种:

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

ICANN 董事会于 2015 年 9 月 28 日当地时间 16:45 在加州的玛丽娜德尔瑞召开了例行会议。

主席 Steve Crocker 准时宣布会议开始。

除主席之外,以下董事也参加了全部或部分会议:Rinalia Abdul Rahim、Cherine Chalaby、Fadi Chehadé(总裁兼首席执行官)、Chris Disspain、Asha Hemrajani、Wolfgang Kleinwächter、Markus Kummer、Bruno Lanvin、Gonzalo Navarro、Ray Plzak、George Sadowsky、Mike Silber、Bruce Tonkin(副主席)和 Kuo-Wei Wu。

以下董事因无法参会而致歉:Erika Mann。

以下董事会联络人参加了全部或部分会议:Ram Mohan(SSAC 联络人)、Thomas Schneider(GAC 联络人)、Jonne Soininen(IETF 联络人)和 Suzanne Woolf(RSSAC 联络人)。

秘书长:John Jeffrey(总法律顾问兼秘书长)。

以下 ICANN 管理人员和员工参加了全部或部分会议:Akram Atallah(全球域名分部总裁);Susana Bennett(首席运营官);Megan Bishop(董事会支持协调人);Michelle Bright(董事会支持内容经理);Xavier Calvez(首席财务官);David Conrad(首席技术官);Samantha Eisner(副总法律顾问);Allen Grogan(首席合同合规官);Dan Halloran(副总法律顾问);Jamie Hedlund(全球域名分部战略项目副总裁);Tarek Kamel(政府合作事务总裁高级顾问);Vinciane Koenigsfeld(董事会支持内容经理);Elizabeth Le(资深法律顾问);Margie Milam(战略计划高级主管);David Olive(政策制定支持副总裁);Erika Randall(资深法律顾问);Amy Stathos(副总法律顾问);Theresa Swinehart(战略事务总裁高级顾问);Shawn White(副总法律顾问)和 Christine Willett(通用顶级域运营副总裁)。

  1. 达成共识的议程:
    1. 批准董事会会议记录
    2. GNSO 理事会针对联系信息的翻译和音译而提出的建议
    3. 续约版《.CAT 注册管理机构协议》
    4. 续约版《.TRAVEL 注册管理机构协议》
    5. 续约版《.PRO 注册管理机构协议》
  2. 主要议程:
    1. 2016 年 6 月 ICANN 会议会址合同
    2. 新 ERP 项目的合同签署和支出政策
    3. 储备金发放 - 美国政府 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

      该 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 号决议),首席执行官或其指定人员将根据指示,以这些建议为基础制定并完成实施计划,并继续针对实施工作与 GNSO 实施审核小组和社群保持沟通与合作。

      第 2015.09.28.02 – 2015.09.28.03 号决议的理由

      为何董事会要立即解决此问题?

      域名系统的国际化进程意味着越来越多的互联网用户将不使用(或者甚至不太熟悉)US ASCII(英语中使用的拉丁字符文字的技术性术语)和其他众多西欧语言。

      对于需要查找域名注册人相关信息的用户而言,联系信息数据的准确性和一致性至关重要。PDP WG 同样考虑了这样一个重要问题:翻译和/或音译的数据或者以注册人最熟悉的文字提交的数据是否更容易满足这些要求?另外还考虑了这些数据的需求量以及与总体翻译或音译相关的成本。

      翻译和音译 PDP 最终报告的第一个建议获得了广泛支持,剩余六个建议则获得了一致支持。该报告同样得到 GNSO 理事会的一致支持。

      根据 ICANN 章程的附录 A,公共评议期结束后,ICANN 董事会需要考量这些建议。

      正在考虑的提案是什么?

      采纳了以下政策建议:

      建议 1 工作组建议,无需将联系信息转换作为强制性要求。任何需要转换的相关方随时都可以通过 WHOIS 之外的方式或任何替换系统(如注册数据访问协议 (RDAP))进行临时转换。如果注册服务机构/注册管理机构未主动承担此责任(请参阅建议 5),那么转换工作就依赖有此要求的相关方自行完成。

      建议 2 尽管 WHOIS 替换系统应该有能力接受非 ASCII 文字形式的联系信息,但工作组建议在存储和显示数据字段时,最好能让用户轻松识别不同数据条目所代表的含义以及注册域名持有人所使用的语言/文字。

      建议 3 工作组建议注册人在提交联系信息数据时,选择使用的语言和文字最好与通用顶级域名提供商的业务模式保持一致。

      建议 4 工作组建议,无论使用哪种语言/文字,数据字段都应该满足《注册服务机构认证协议》(RAA)、相关共识性政策、附加 WHOIS 信息政策 (AWIP) 以及其他所有适用政策所确定的标准。应该根据前述政策和协议验证所输入的信息数据,且所使用的语言/文字必须容易辨识。

      建议 5 工作组建议,如果执行联系信息转换,且如果 WHOIS 替换系统有能力让每个注册域名持有人条目显示多个数据集,那么这些数据应该显示为附加字段(作为注册人提供的权威本土文字字段的补充),且这些字段应该标记为"已转换",同时标注其源语言。

      建议 6 工作组建议,任何 WHOIS 替换系统(如 RDAP)都应该保持灵活性,以便有能力以新的语言/文字添加联系信息,同时提高其接收、存储和显示联系信息数据的语言/文字能力。

      建议 7 工作组建议,这些建议应该与其他适用的 WHOIS 修改内容保持一致,一旦 WHOIS 替换系统有能力接收、存储和显示非 ASCII 字符,这些建议即可实施。

      与章程问题二相关的结论根据建议 1-7,我们尚未明确由谁决定将联系信息翻译或音译为单一通用文字。

      Finding in relation to second Charter questionBased on recommendations #1-#7, the question of who should decide who should bear the burden of translating or transliterating contact information to a single common script is moot.

      有一种关于建议 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 注册管理机构协议》,将授权总裁兼首席执行官或其指定人员采取相应行动,确保完成和执行该协议。

      第 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 注册管理机构协议》中,这些意见称,只有经过完整的政策制定流程 (PDP) 并得到全体 ICANN 利益相关方社群的参与,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 和注册管理运行机构的协商成果确定的,续约条款得到了 ICANN 和注册管理运行机构的一致认可。受董事会批准的续约条款是针对当前《注册管理机构协议》的双边协商的成果,向新形式的《注册管理机构协议》转换不会违反现有的 GNSO 政策。如下所述,新形式的《注册管理机构协议》提供了某些运营优势,能够让注册人和互联网社群获利,包括公益承诺、需要使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到紧急阈值时,有能力指定临时性紧急注册管理运行机构。

      会对社群产生积极还是消极的影响?

      作为续约流程的一部分,ICANN 根据当前《.CAT 注册管理机构协议》,对注册管理运行机构的近期绩效进行了审核。审核结果显示,注册管理运行机构基本上满足其合同要求。

      董事会批准续约版《注册管理机构协议》同样能够带来积极的技术和运营利益。根据续约版《注册管理机构协议》的内容,如果注册管理机构职能达到任何紧急阈值,那么注册管理运行机构允许 ICANN 指定临时性紧急注册管理运行机构,负责处理顶级域名的注册事宜,此举将减轻域名系统的稳定性和安全性风险。另外,注册管理运行机构将根据新通用顶级域名协议的条款进行技术加盟,这将促使注册管理机构使用统一的自动化流程,从而让顶级域名的运营更加便利。续约版《注册管理机构协议》同样包括一系列保护措施,具体体现在规格 11 的公益承诺中。

      续约也将对注册服务机构和注册人带来积极影响。向新通用顶级域名《注册管理机构协议》转换将为所有注册管理机构提供一致性,有助于为最终用户打造更具可预测性的环境,此外,拟定的续约版《注册管理机构协议》要求注册管理运行机构使用 ICANN 认证的注册服务机构(即《2013 注册服务机构认证协议》(RAA) 签约方),这将为注册服务机构和注册人带来更大利益。

      保护权利持有人:新通用顶级域名协议将允许注册管理运行机构采用其他权利保护机制来保护权利持有人。

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

      如果 ICANN 批准拟定的续约版《.CAT 注册管理机构协议》,并不会带来重大的财务影响。但值得一提的是,批准续约版《注册管理机构协议》后,注册管理机构年费预计将从 112,000 美元下降为 56,000 美元。《注册管理机构协议》将为注册人和互联网社群带来更多利益,包括公益承诺、需要使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到紧急阈值时,有能力指定临时性紧急注册管理运行机构,这些将抵销所谓的财务影响。

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

      如果 ICANN 批准拟定的续约版《.CAT 注册管理机构协议》,预计不会发生与 DNS 相关的任何安全性、稳定性或灵活性问题。拟定的续约版《注册管理机构协议》实际上包括一系列有利条款,如果 DNS 的安全性或稳定性受到威胁,ICANN 可以更快速地采取行动。作为 ICANN 组织管理职能的一部分,2015 年 5 月 28 日,ICANN 发布了续约版《注册管理机构协议》草案以征询公共评议。

    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 月 5 日结束,ICANN 收到了个人和组织/小组所提交的十五 (15) 份意见。董事会对意见进行了总结和分析。

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

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

      第 2015.09.28.05 号决议的理由

      为何董事会要立即解决此问题?

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

      正在考虑的提案是什么?

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

      考虑到 .TRAVEL 顶级域名的具体性质,续约版《注册管理机构协议》纳入了 2005 年 5 月 5 日社群性通用顶级域名《注册管理机构协议》中与社群性通用顶级域名相关的条款。具体来说,规格 12 体现了章程中的相应条款,概述了符合社群意义并拥有注册资格的旅游行业领域的情况。续约版《注册管理机构协议》同样反映了此前与保留名称相关的审批情况。

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

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

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

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

      • 传统顶级域名向新通用顶级域名《注册管理机构协议》的形式进行转换:ICANN 计划使用新通用顶级域名《注册管理机构协议》作为传统通用顶级域名续约版《注册管理机构协议》的起点,有些公众意见表达了对此进程的困惑。这些评议者表示,如果采用这种方式,那么将新通用顶级域名授权后争议解决程序(例如,商标授权后争议解决程序和公益承诺争议解决流程)以及统一快速中止程序 (URS) 转化为共识性政策时,没有遵循 ICANN 章程中规定的相应程序。另一方面,有其他意见表示支持 ICANN 保持注册管理机构协议的一致性,并认为向新的协议形式转换也是受许可的双边协商的一部分。
      •  无需政策制定流程 (PDP),在传统顶级域名续约中纳入统一快速终止程序 (URS) 和商标争议解决程序 (PDDRP):所收到的大部分意见都反对将 URS 纳入拟定的续约版《.TRAVEL 注册管理机构协议》中,这些意见称,只有经过完整的政策制定流程 (PDP) 并得到全体 ICANN 利益相关方社群的参与,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 和注册管理运行机构的协商成果确定的,续约条款得到了 ICANN 和注册管理运行机构的一致认可。受董事会批准的续约条款是针对当前《注册管理机构协议》的双边协商的成果,向新形式的《注册管理机构协议》转换不会违反现有的 GNSO 政策。如下所述,新形式的《注册管理机构协议》提供了某些运营优势,能够让注册人和互联网社群获利,包括公益承诺、需要使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到紧急阈值时,有能力指定临时性紧急注册管理运行机构。

      会对社群产生积极还是消极的影响?

      作为续约流程的一部分,ICANN 根据当前《.TRAVEL 注册管理机构协议》,对注册管理运行机构的近期绩效进行了审核。审核结果显示,注册管理运行机构基本上满足其合同要求。

      董事会批准续约版《注册管理机构协议》同样能够带来积极的技术和运营利益。根据续约版《注册管理机构协议》的内容,如果注册管理机构职能达到任何紧急阈值,那么注册管理运行机构允许 ICANN 指定临时性紧急注册管理运行机构,负责处理顶级域名的注册事宜,此举将减轻域名系统的稳定性和安全性风险。另外,注册管理运行机构将根据新通用顶级域名协议的条款进行技术加盟,这将促使注册管理机构使用统一的自动化流程,从而让顶级域名的运营更加便利。续约版《注册管理机构协议》同样包括一系列保护措施,具体体现在规格 11 的公益承诺中。

      续约也将对注册服务机构和注册人带来积极影响。向新通用顶级域名《注册管理机构协议》转换将为所有注册管理机构提供一致性,有助于为最终用户打造更具可预测性的环境,此外,拟定的续约版《注册管理机构协议》要求注册管理运行机构使用 ICANN 认证的注册服务机构(即《2013 注册服务机构认证协议》(RAA) 签约方),这将为注册服务机构和注册人带来更大利益。

      保护权利持有人:新通用顶级域名协议将允许注册管理运行机构采用其他权利保护机制来保护权利持有人。

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

      如果 ICANN 批准拟定的续约版《.TRAVEL 注册管理机构协议》,并不会带来重大的财务影响。但值得一提的是,批准续约版《注册管理机构协议》后,注册管理机构年费预计将从 46,000 美元下降为 25,000 美元。《注册管理机构协议》将为注册人和互联网社群带来更多利益,包括公益承诺、需要使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到紧急阈值时,有能力指定临时性紧急注册管理运行机构,这些将抵销所谓的财务影响。

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

      如果 ICANN 批准拟定的续约版《.TRAVEL 注册管理机构协议》,预计不会发生与 DNS 相关的任何安全性、稳定性或灵活性问题。拟定的续约版《注册管理机构协议》实际上包括一系列有利条款,如果 DNS 的安全性或稳定性受到威胁,ICANN 可以更快速地采取行动。作为 ICANN 组织管理职能的一部分,2015 年 5 月 12 日,ICANN 发布了续约版《注册管理机构协议》草案以征询公共评议。

    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 注册管理机构协议》,将授权总裁兼首席执行官或其指定人员采取相应行动,确保完成和执行该协议。

      第 2015.09.28.06 号决议的理由

      为何董事会要立即解决此问题?

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

      正在考虑的提案是什么?

      董事会批准的续约版《注册管理机构协议》包含一系列修改的条款,将与新通用顶级域名《注册管理机构协议》的形式保持一致。修改内容包括:更新了技术规范;需要纳入某些 GAC 保护措施作为公益承诺(根据公益承诺争议解决流程予以实施);达到特定阈值后,需使用签署了《2013 注册服务机构认证协议》的注册服务机构;删除了可以向注册服务机构收取的最高注册费用限制。

      具体而言,《.PRO 协议》附录 11 的现有注册限制,预计将由适用于所有新通用顶级域名的一系列标准公益承诺替换。然而,拟定的续约版《注册管理机构协议》已进行了更新,其中包含与三级域名注册相关的条款。此外,规格 11 中添加了 GAC 第 1 类的第 1 至第 3 条保护措施。同时,续约版《注册管理机构协议》也删除了可向注册服务机构收取的域名注册相关服务最高费用限制,并反映了此前与保留名称相关的审批情况。

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

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

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

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

      • 传统顶级域名向新通用顶级域名《注册管理机构协议》的形式进行转换:ICANN 计划使用新通用顶级域名《注册管理机构协议》作为传统通用顶级域名续约版《注册管理机构协议》的起点,有些公众意见表达了对此进程的困惑。这些评议者表示,如果采用这种方式,那么将新通用顶级域名授权后争议解决程序(例如,商标授权后争议解决程序和公益承诺争议解决流程)以及统一快速中止程序 (URS) 转化为共识性政策时,没有遵循 ICANN 章程中规定的相应程序。另一方面,有其他意见表示支持 ICANN 保持注册管理机构协议的一致性,并认为向新的协议形式转换也是受许可的双边协商的一部分。
      • 无需政策制定流程 (PDP),在传统顶级域名续约中纳入统一快速终止程序 (URS) 和商标争议解决程序 (PDDRP):所收到的大部分意见都反对将 URS 纳入拟定的续约版《.PRO 注册管理机构协议》中,这些意见称,只有经过完整的政策制定流程 (PDP) 并得到全体 ICANN 利益相关方社群的参与,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 和注册管理运行机构的协商成果确定的,续约条款得到了 ICANN 和注册管理运行机构的一致认可。受董事会批准的续约条款是针对当前《注册管理机构协议》的双边协商的成果,向新形式的《注册管理机构协议》转换不会违反现有的 GNSO 政策。如下所述,新形式的《注册管理机构协议》提供了某些运营优势,能够让注册人和互联网社群获利,包括公益承诺、需要使用签署了 2013 RAA 的注册服务机构,以及 ICANN 在关键注册管理机构服务达到紧急阈值时,有能力指定临时性紧急注册管理运行机构。

      会对社群产生积极还是消极的影响?

      作为续约流程的一部分,ICANN 根据当前《.PRO 注册管理机构协议》,对注册管理运行机构的近期绩效进行了审核。审核结果显示,注册管理运行机构基本上满足其合同要求。

      董事会批准续约版《注册管理机构协议》同样能够带来积极的技术和运营利益。根据续约版《注册管理机构协议》的内容,如果注册管理机构职能达到任何紧急阈值,那么注册管理运行机构允许 ICANN 指定临时性紧急注册管理运行机构,负责处理顶级域名的注册事宜,此举将减轻域名系统的稳定性和安全性风险。另外,注册管理运行机构将根据新通用顶级域名协议的条款进行技术加盟,这将促使注册管理机构使用统一的自动化流程,从而让顶级域名的运营更加便利。续约版《注册管理机构协议》同样包括一系列保护措施,具体体现在规格 11 的公益承诺中,包括 GAC 第 1 类的第 1 至第 3 条保护措施。

      续约也将对注册服务机构和注册人带来积极影响。向新通用顶级域名《注册管理机构协议》转换将为所有注册管理机构提供一致性,有助于为最终用户打造更具可预测性的环境,此外,拟定的续约版《注册管理机构协议》要求注册管理运行机构使用 ICANN 认证的注册服务机构(即《2013 注册服务机构认证协议》(RAA) 签约方),这将为注册服务机构和注册人带来更大利益。

      保护权利持有人:新通用顶级域名协议将允许注册管理运行机构采用其他权利保护机制来保护权利持有人。

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

      如果 ICANN 批准拟定的续约版《.PRO 注册管理机构协议》,并不会带来重大的财务影响。

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

      如果 ICANN 批准拟定的续约版《.PRO 注册管理机构协议》,预计不会发生与 DNS 相关的安全性、稳定性或灵活性问题。拟定的续约版《注册管理机构协议》实际上包括一系列有利条款,如果 DNS 的安全性或稳定性受到威胁,ICANN 可以更快速地采取行动。作为 ICANN 组织管理职能的一部分,2015 年 5 月 28 日,ICANN 发布了续约版《注册管理机构协议》草案以征询公共评议。

    所有出席的董事会成员均投票赞同决 2015.09.28.01、2015.09.28.02、2015.09.28.03、2015.09.28.04、2015.09.28.05 和 2015.09.28.06。Wolfgang Kleinwächter、Erika Mann 和 Bruce Tonkin 无法针对决议进行投票。决议通过。

  2. 主要议程:

    1. 2016 年 6 月 ICANN 会议会址合同

      财务委员会主席 Cherine Chalaby 介绍了会议议项。2016 年 6 月的 ICANN 会议预计将在巴拿马的巴拿马城召开。Cherine 指出,与新加坡、布宜诺斯艾利斯以及都柏林等其他会址相比,该会址的总体会议成本极具竞争力,较为实惠。董事会讨论指出,2016 年 6 月的会议是第一场类型"B"的公共会议,与该年度其他两次标准 ICANN 公共会议相比,该会议的持续天数较短,活动也较少。

      Cherine 提出决议并得到 George Sadowsky 的支持,董事会接下来采取了以下行动:

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

      员工对拟定的拉丁美洲/加勒比海地区会址进行了全面审核,并认为巴拿马的巴拿马城最为合适。

      已决定(第 2015.09.28.07 号决议),董事会授权总裁兼首席执行官或其指定人员,要求其针对 2016 年 6 月于巴拿马的巴拿马城举行的 ICANN 公开会议确定接待酒店/会议中心,参与并促进与之相关的必要合同和支出事宜,会议总成本不得超过 110 万美元。

      已决定(第 2015.09.28.08 号决议),根据 ICANN 章程第 III 条第 5.2 节的规定,考虑到协商需求,此决议的具体条款应该保密,除非总裁兼首席执行官决定公布此机密信息。

      所有出席会议的董事会成员均投票赞成第 2015.09.28.07 号和第 2015.09.28.08 号决议。Wolfgang Kleinwächter、Erika Mann 和 Bruce Tonkin 无法针对决议进行投票。决议通过。

      第 2015.09.28.07 - 2015.09.28.08 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,ICANN 每年将在世界不同的地理区域(根据 ICANN 章程中的定义)召开三次会议。ICANN 第 56 届会议定于 2016 年 6 月 27 日至 30 日在拉丁美洲/加勒比海地理区域内召开。2015 年 3 月 23 日,ICANN 呼吁各成员提供关于拉丁美洲/加勒比海地区会址的建议。各相关方为 ICANN 发送了一份提案。

      员工对推荐的会址和其他会址进行了全面分析,并制定了一份文件,确定了满足会址选择标准(请参阅 http://meetings.icann.org/location-selection-criteria)的地区。根据建议和分析,ICANN 确定将巴拿马的巴拿马城作为 ICANN 第 56 届会议的会址。

      针对 2016 年 6 月的 ICANN 公共会议,董事会审核了员工关于在巴拿马的巴拿马城举行会议的简报,并确定提案满足会址选择标准的关键要素,且所选会址满足相关成本要求。

      主办会议并提供必要的差旅补助会对 ICANN 产生财务影响,也会给承担会议差旅成本的社群带来财务影响。但无论会议在何地举行,这种影响始终存在。此行动不会对 DNS 的安全性或稳定性造成影响。

      董事会感谢对 ICANN 第 56 届会议的选址提出建议的所有人员!

      这是一项组织管理职能,不需要公共评议。

    2. 新 ERP 项目的合同签署和支出政策

      财务委员会主席 Cherine Chalaby 介绍了会议议项。财务委员会建议董事会批准使用全新集成式企业资源规划 (ERP) 解决方案替换当前的财务、人力资源和采购后勤办公系统基础设施的相关合同和支出,该解决方案将对整个组织提供支持。在单一记录系统中保护并实施集成式 ERP 解决方案将提升系统性能、全球报告和分析能力、生产效率和跨职能效率,同时将强化内部控制能力。Cherine 也指出,相对于改进现有系统,实施新的 ERP 解决方案将更具成本效益。

      Cherine 提出决议并得到 Ray Plzak 的支持,董事会接下来采取了以下行动:

      ICANN 需要采购集成式企业资源规划 (ERP) 解决方案。

      在 2015 年 9 月 11 日的会议中,董事会财务委员会审核了全新 ERP 项目的财务影响并考虑了其他替代方案。

      董事会风险委员会的某些成员审核了所推荐的 ERP 解决方案并为员工提供了关于风险和实用缓解措施的指南。

      员工和董事会财务委员会都建议董事会向总裁兼首席执行官或其指定人员授权,要求其采取所有必要措施履行新 ERP 项目相关合同(具体请参阅本文件的"参考资料"部分),并确保所有必要支出与合同条款保持一致。

      已决定(第 2015.09.28.09 号决议),董事会授权总裁兼首席执行官或其指定人员,要求其采取所有必要措施履行新 ERP 解决方案相关合同(具体请参阅本文件的"参考资料"部分),并确保所有必要支出与合同条款保持一致。

      已决定(第 2015.09.28.10 号决议),根据 ICANN 章程第 III 条第 5.2 节的规定,考虑到协商需求,此决议的具体条款应该保密,除非总裁兼首席执行官决定公布此机密信息。

      所有出席会议的董事会成员均投票赞成第 2015.09.28.09 号和第 2015.09.28.10 号决议。Erika Mann 无法针对决议进行投票。决议通过

      第 2015.09.28.09 – 2015.09.28.10 号决议的理由

      在过去五年里,ICANN 的规模和复杂程度日益增长,具体包括但不限于:(i) 员工数量增长了三倍;(ii) 全球影响力急剧上升,在全球拥有三个办公中心和几大合作中心;(iii) 流程更具全球化、更加复杂。同时,用以支持当前组织的各个独立的财务、人力资源和采购后勤办公系统基础设施至少是五年之前设计和实施的。在单一记录系统中保护并实施集成式企业资源规划 ERP 解决方案将提升系统性能、全球报告和分析能力、生产效率和跨职能效率,同时将强化内部控制能力,从而促进 ICANN 在卓越运营方面取得长足发展。

      员工针对以下两大可用方案进行了全面分析:(i) 改进现有系统,略微提升系统性能并视需要开发界面;(ii) 实施集成式 ERP 解决方案。尽管改进选项的成本在第一年相对较低,但五年总成本将大大超出集成式 ERP 方案,因为在接下来的五年内,系统仍然需要进行重要升级。此外,改进只能略微提高后勤办公系统的性能和效率,而且需要开发成本高昂、操作复杂和维护困难的界面,这将导致各种性能大大低于集成式解决方案。

      因此,集成式 ERP 解决方案是更适用、更具成本效益的解决方案。

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

      内部资源:该项目在很早之前就得到过考量,但迟迟没有开展。直到我们雇佣了经验丰富的高级人才,并经过所有业务部门(IT、财务、人力资源和采购)的参与后,项目才达到适当的成熟度。ICANN 于 2014 年雇佣了高级信息技术总监,于 2015 年雇佣了财务副总裁,两者在大型系统实施项目方面均拥有丰富的经验,因此可以满足相关条件。内部资源包括:

      1. 三名主题专家小组:每个小组都拥有两个方面的专家(一名领导以及每种职能方面的专家)
      2. 四名后备人才:涵盖设计和实施阶段,可确保日常运营活动正常开展,同时对 ERP 项目投入适当的专家关注度
      3. 一名拥有丰富的 ERP 实施经验的专属项目经理(属合同型编制人员)。
      4. 三名信息技术人才:一名高级信息技术总监(监督和管理)、一名信息技术业务分析师和一名信息技术经理(一名负责人力资源,一名负责财务/采购)
      5. 指导委员会包括:首席创新与信息官、首席运营官、首席财务官和高级信息技术总监
      6. 一名人力资源变更管理人才(待招聘)
      7. 自项目创立以来所开展的全面审核。

      外部资源:

      1. 规模较大的 ERP 提供商,拥有大型认证业务合作伙伴网络和内部咨询资源,ICANN 可以借鉴相关经验。
      2. 规模较大的 ERP 提供商,拥有大型认证业务合作伙伴网络和内部咨询资源,ICANN 可以借鉴相关经验。

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

      1. 一个可直接配置的基于 Web 的平台,解决方案提供商的所有客户均可使用
      2. 每名客户均可根据业务部门的需求配置各种功能(无需开发软件、无需自定义)
      3. 对于每种职能,标准流程和可选流程的范围均根据流程和控制最佳实践予以设计,可以直接配置。
      4. 平台将得到定期更新,平台中的所有客户均可通过各种方式使用新功能,且无需额外成本
      5. SaaS 提供商将根据服务级别协议 (SLA) 监控和管理系统性能

      系统安全性

      1. 数据传输:设计了多步数据转换策略,包括测试、调整和验证流程。
        1. ICANN 将转换历史交易数据和所有主文档数据。
        2. 所有转换项目都将经过彻底的准确性和完整性测试。
        3. ICANN 将执行单元测试,并进行两大会议室模拟 (CRP),可测试系统配置和数据文件转换的业务流程。
        4. ICANN 将执行业务模拟测试,从开始到结束,完整模拟实际的业务流程(例如,从订购到收款以及从采购到付款),此外,ICANN 将对历史数据和主文档数据执行完整的转换测试。
      2. 数据安全性:RFP 流程包括灾难恢复、数据中心运营管理、数据加密、数据日志以及 ICANN 专属 ERP 环境演示:
        1. ICANN 将配置世界级的数据安全标准,包括数据加密、访问控制管理、系统日志访问和审查以及根据良好的内部控制来配置访问安全性。

      此外,董事会审核了员工和董事会财务委员会关于全新 ERP 解决方案的合同和开支审批权的建议。

      实施全新 ERP 解决方案将对 ICANN 造成财务影响。该影响目前包括在董事会于 2015 年 6 月 25 日批准的 2016 财年运营规划和预算中。此举措不会对域名系统的安全性、稳定性和灵活性造成直接影响。

      这是一项组织管理职能,不需要公共评议。

    3. 储备金发放 - 美国政府 IANA 管理权移交成本

      财务委员会主席 Cherine Chalaby 介绍了会议议项。董事会之前授权从储备金中拨出 2015 财年与美国政府 IANA 管理权移交活动相关的费用开支,金额不超过 700 万美元。由于 CCWG 和 CWG 要求提供外部独立法律顾问,因而产生了额外费用,美国政府移交项目的总体成本现已超过 2015 财年的初始预算计划(目前的已发生成本为 870 万美元)。因此,财务委员会建议董事会授权从储备金中拨出相应资金,以冲抵 170 万美元的已发生成本。

      董事会参加了与美国政府 IANA 管理权移交活动成本超额相关的讨论。几名董事会成员针对未来工作的责任和有效支出以及成本控制措施发表了看法,希望避免成本失控情况的发生。董事会深入讨论了针对未来的类似开支设置参数和预期的相关问题。董事会研究了采取节约内部成本的措施来抵销储备金超额支出的可能性。此外,董事会还讨论了审核成本和支出轨迹、储备金预期、2016 财年和 2017 财年计划以及五年运营规划的需求,希望针对如何维护储备金和降低支出提供建议。

      Cherine 提出决议并得到 Gonzalo Navarro 的支持,董事会接下来采取了以下行动:

      2015 年 4 月 26 日,董事会授权从储备金中拨出 2015 财年与美国政府 IANA 管理权移交活动相关的成本开支,金额不超过 700 万美元。

      ICANN 2015 财年实际花费的相关成本为 870 万美元,其中包括 310 万美元未预见到的独立法律意见成本。

      董事会强调了于 2015 年 6 月 25 日所发布的声明,即,董事会"承诺支持社群获取与移交流程建议相关的意见,同时需要确保社群以负责且有效的方式使用分配给 ICANN 的资金。鼓励社群继续针对独立法律顾问的未来工作采取成本控制措施。"(请参阅 https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c)。

      董事会财务委员会建议董事会授权从储备金中拨出 2015 财年与美国政府 IANA 管理权移交活动相关的费用开支 870 万美元,董事会同意该建议。

      已决定(第 2014.09.28.11 号决议),董事会授权总裁兼首席执行官或其指定人员从储备金中拨出 870 万美元,以冲抵 2015 财年与美国政府 IANA 管理权移交活动相关的已发生成本。

      十二名出席会议的董事会成员投票赞成第 2015.09.28.11 号决议。Ray Plzak 和 Kuo-Wei Wu 投票反对第 2015.09.28.11 号决议。Wolfgang Kleinwächter 投了弃权票。Erika Mann 无法针对决议进行投票。决议通过。

      第 2015.09.28.11 号决议的理由

      美国政府 IANA 管理权移交活动是一项重要活动,整个 ICANN 社群对此投入了大量的时间和资源。ICANN 为社群成功完成本项目(包括美国政府 IANA 管理权移交提案的制定和问责制工作)而提供的支持对 ICANN 而言至关重要。

      考虑到项目的特殊性以及预计将发生的高额成本,项目资金无法通过 ICANN 年度运营收入予以提供。因此,董事会在批准 2015 财年运营规划和预算时,纳入了通过相应储备金发放的项目预计成本(700 万美元)。

      因 2015 财年发生了与此项目相关的成本,董事会批准从储备金中拨出相应资金,以冲抵 2015 财年与美国政府 IANA 管理权移交活动相关的实际成本,最高金额为 700 万美元,该费用已纳入董事会批准的 2015 财年运营规划和预算中。

      2015 财年实际发生的项目相关总成本为 870 万美元,超过了董事会在其 2015.04.26.17 号决议中授权拨出的 700 万美元的储备金费用,因此 ICANN 申请董事会批准从储备金中拨出相应费用,以冲抵总实际成本 870 万美元。此举措不会对域名系统的安全性、稳定性和灵活性造成直接影响。

      这是一项组织管理职能,不需要公共评议。

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

      全球域名分部总裁 Akram Atallah 介绍了会议议项。有人要求董事会考虑下一轮新通用顶级域项目的流程和时限。2012 轮次的审核工作目前正在进行。董事会讨论了在推行下一轮次之前完成所有审核工作以及审核评估工作的重要意义,因为审核及其评估成果有助于确定下一轮次开始的时间和方式。社群完成审核与评估工作后,董事会将有能力提供开展下一轮新通用顶级域项目的时限。

      Chris Disspain 提出此决议并得到 Cherine Chalaby 的支持,董事会接下来采取了以下行动:

      董事会决议 2012.02.07.05 重申了 ICANN 关于尽快开启下一轮新通用顶级域项目的承诺。

      2012 轮次新通用顶级域项目的审核工作目前正在进行。

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

      已决定(第 2015.09.28.12 号决议),董事会指示 ICANN 员工继续如期开展新通用顶级域项目的审核工作,同时鼓励利益相关方社群参与相关工作,为确定可靠而有意义的审核流程提供支持。

      已决定(第 2015.09.28.13 号决议),董事会将耐心跟进社群的工作进展,一旦审核流程和潜在 GNSO 政策制定流程达到更高级的阶段,董事会将考虑针对未来轮次提供指南。

      所有出席会议的董事会成员均投票赞成第 2015.09.28.12 号和第 2015.09.28.13 号决议。Erika Mann 无法针对决议进行投票。决议通过。

      第 2015.09.28.12 – 2015.09.28.13 号决议的理由

      为何董事会要立即解决此问题?

      众多审核工作与社群活动目前正在进行,这些工作有助于确定下一轮次开始的时间和推行方式。有人要求董事会考虑下一轮新通用顶级域项目的流程和时限,以便为 ICANN 的长期规划、分析和预算制定工作提供帮助,从而确保下一轮次更加有效。

      考虑了哪些提案?

      董事会考虑了目前正在进行的众多审核流程和社群活动的开展情况,并将确定下一轮新通用顶级域项目开始的时间和方式。董事会考虑了三个方案。第一个方案是确定社群针对未来轮次提供建议的目标日期,并提供完成审核流程和可能的 PDP 的大概时限。该方案没有向任何相关方提供严格的审核或政策制定活动完成时限,而是提供了大概时限,有助于所有相关方完成其规划。第二个方案是确定预期流程,董事会首先将考虑审核结果,然后要求员工制定实施规划和时限。第三个方案是暂不确定下一轮次的时限或各种先决条件,等审核流程和/或 PDP 达到更高级的阶段再予以确定。

      董事会目前的行动是鼓励社群继续实施并参与当前的审核流程,等审核工作进入更高级阶段后,提供关于未来轮次的规划。

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

      2014 年 9 月初,ICANN 员工发布了关于新通用顶级域审核工作计划草案并收集了反馈意见。4 新通用顶级域后续程序 GNSO 讨论组在探讨政策影响和开发新通用顶级域项目的过程中扮演了重要角色。尽管尚未正式咨询 GNSO 的建议,有一个问题在小组讨论中反复出现:在下一轮次的发展过程中,有哪些未来的流程是应该考虑的?此外,缔约方、新注册管理运行机构、互联网服务提供商和 IP 运营商等社群利益相关方以及最终用户社群成员都针对下一轮次的时限提出了自己的建议。

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

      董事会审核了工作计划草案、《义务确认书》(AoC)、审核工作完成的大致时间(基于工作计划中所述活动的初步估算)、2015 年 8 月 31 日的 GNSO 初步问题报告、作为报告基础的 GNSO 讨论、关于承诺尽快推行第二轮次的决议 2012.02.07.05 和 2014.11.17.10、相关利益相关方小组的咨询意见,以及旨在减少新通用顶级域项目潜在问题的保护措施的权利保护机制审核。

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

      考虑到审核流程的结果未知,且可能启动 PDP,在早期阶段确定下一轮新通用顶级域的开始时间不太实际。董事会理解利益相关方社群希望获得更明确的信息,但认为目前的工作重点是针对当前轮次开展有意义的审核。董事会后期将对未来轮次的时间安排和流程进行探讨。

      会对社群产生积极还是消极的影响?

      因目前缺乏明确的时限或流程承诺,有些社群可能会感到失望。然而,董事会的行动将确保审核流程得到重视,第一轮新通用顶级域项目的成果得到全面评估。某些选区询问过目前所开展的众多审核工作与流程对第二轮次的启动有何意义,在他们看来,此举可能是对问题的回避。然而,这种方式有助于社群针对确定相关步骤之前需要解决的重要领域问题继续保持对话。如果没有充分的时间开展审核工作,太快进入下一轮次,那么社群可能无法认真思考从第一轮次中获取的经验教训,而这些是下一轮次得以发展的重要部分。此外,做出时限承诺或提供预计流程可能让利益相关方社群抱有关于第二轮次开始时间的不切实际的预期。

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

      某些项目审核工作需要特别专家成员的参与,2016 财年预算中已经分配了相关活动的资金。然而,此决议尚未规划和/或分配的工作预计不会对预算带来其他影响。

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

      此决议不会对 DNS 的安全性、稳定性或灵活性造成即时影响,但需要注意,DNS 的安全性、稳定性和灵活性是计划研究的领域之一。

      这是 ICANN 支持组织的明确政策流程,还是 ICANN 组织管理职能决策?是否需要征询公众意见?

      由于第一轮通用顶级域项目的评估工作尚未完成,且尚未创建明确的政策流程,所以目前尚无明确的政策流程。但审核工作和 PDP 完成后,需要就此征询公众意见。

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

      风险委员会的联合主席 Mike Silber 介绍了会议议项。注册服务机构认证政策要求注册服务机构将商业综合责任保险 (CGL) 的保额政策维持在至少 50 万美元的额度内,如果注册服务机构能够证明,即使出现了保险覆盖范围内的损失,较低的保额仍可以提供合理的补偿,那么可将限额设置得更低一些。《注册服务机构认证协议》(RAA) 要求注册服务机构将保额维持在 50 万美元的水平。ICANN 已收到有关反馈,反馈认为 RAA 的 CGL 保险要求没有进一步体现注册服务机构认证政策的声明中有关 CGL 保险要求的意图:当注册服务机构在承保范围内出现不当行为时,可向注册人提供补偿。此外,迄今为止尚未触及保险范围。关于这项保险要求对发展中国家/地区的注册服务机构市场发展造成阻碍一事,董事会已展开进一步讨论。基于上述信息,董事会讨论了对 CGL 保险要求实施免除这一事宜。

      Mike 提出决议并得到 Gonzalo Navarro 的支持,董事会接下来采取了以下行动:

      在 1999 年采纳的 ICANN 注册服务机构认证政策(以下简称"认证政策")声明中,要求注册服务机构必须设置商业综合责任保险 (CGL),并将保额政策维持在至少 50 万美元的限额,如果注册服务机构能够证明,即使出现了保险覆盖范围内的损失,较低的保额仍可以提供合理的补偿,那么可将限额设置得更低一些。

      《注册服务机构认证协议》要求注册服务机构将保额维持在 50 万美元的水平(并没有参考认证政策提出的较低的保额限制)。

      ICANN 已收到有关反馈,反馈认为 RAA 的 CGL 保险要求没有进一步体现注册服务机构认证政策的声明中有关 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 号决议。Erika Mann 无法针对这两项决议进行投票。决议通过。

      第 2015.09.28.14 号和第 2015.09.28.15 号决议的理由

      为何董事会要立即解决此问题?

      2009 年和 2013 年的《注册服务机构认证协议》要求注册服务机构在获得商业综合责任保险时,必须将保额政策维持在至少 50 万美元的额度内。此要求基于 ICANN 注册服务机构认证政策声明中的一段话,这段话表明注册服务机构必须设置商业综合责任保险 (CGL),并将保额政策维持在至少 50 万美元的额度内,如果注册服务机构能够证明,即使出现了保险覆盖范围内的损失,较低的保额仍可以提供合理的补偿,那么可将限额设置得更低一些。然而,在 RAA 的要求中,没有纳入认证政策的声明中所涉及的采取灵活策略,可降低政策保额限制。

      CGL 保险政策通常可以保护企业免遭因发生在企业中的人身伤害和财产损失而导致的责任索赔,以及在某些情况下因广告和人身伤害责任而导致的责任索赔。然而,大部分 CGL 政策都会避免涵盖由注册服务机构造成的错误和疏忽。换句话说,对于由注册服务机构造成的疏忽行为(例如,意外删除或未能续约注册,或者允许域名被劫持),域名持有者通常无法从保险公司获得补偿(根据 CGL 政策)。

      对于那些希望成为 ICANN 认证的注册服务机构的实体而言,此项保险要求对他们在财务方面和实际情况中都构成了挑战。社群的意见认为,当这种保险类型过于昂贵和/或在没有这种保险的地方,此项要求会大大地削弱注册服务机构和潜在的注册服务机构的优势。

      为此,董事会正在采取措施,以批准免除 2009 年和 2013 年 RAA 中的现有 CGL 保险要求,因为商业综合责任保险要求不仅没有进一步推进既定政策目标,而且还给潜在的注册服务机构带来了过度的负担。尽管征询了大量的公众意见,但没有证据表明 CGL 要求能够为注册人带来任何益处。

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

      ICANN 收到了潜在注册服务机构的反馈,反馈表明在他们所在的地区很难或不可能获得这项要求的保险。ICANN 在 2014 年的新加坡会议期间召开了一次研讨会,专门讨论了这个问题以及其他与服务水平低下的地区相关的主题。ICANN 曾咨询外部保险顾问以及多家现有和潜在的注册服务机构。ICANN 针对这个主题进行了两轮公众意见征询:2014 年 5 月2015 年 1 月。作为董事会举措的一部分,董事会鼓励 GNSO 审查此问题。

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

      社群成员曾向 ICANN 报告,许多司法管辖区都难以满足或无法满足现有的保险要求,这种情况在北美和欧洲以外的司法管辖区尤为突出。有些人认为某些国家/地区根本就没有 CGL 保险,即使其他一些国家/地区设立了这项保险,但是相对于各自国家/地区的市场状况、生活费用和经商所存在的风险来说,50 万美元的保额限制可能过高(因此,从商业角度考虑并不可行)。此外,一些评论人员质疑,鉴于 ICANN 在其他领域开展的制度改进工作(例如,强化合规和数据托管),是否还有必要继续保留这些要求。一些社群成员建议,ICANN 可以向新的和现有的注册服务机构提供一份保险公司名单,这些保险公司能够为现有的注册服务机构企业办理保险业务,进而可以让注册服务机构享受获取 ICANN 认证所需的保险。

      不过,还有其他一些社群成员则建议保持谨慎态度,他们认为如果免除了 CGL 要求,注册人可能就无法受到保护。

      董事会在制定这项决策时参考了哪些材料?

      为了制定此决策,董事会参考了分别于 2014 年 9 月 2 日 2015 年 4 月 3 日发布的关于这个问题的两份公众意见报告以及董事会参考材料。另外,董事会还参考了注册服务机构认证政策声明,以及 2009 年和 2013 年《注册服务机构认证协议》。

      董事会在制定此决策时认为至关重要的因素有哪些?

      目前的保险要求没有按照其最初的既定目标提供服务:保护注册人免遭注册服务机构不当行为的侵害。而且,该项要求还压制了世界上服务水平低下的地区的竞争。由于最初这项保险要求是关乎 ICANN 政策的事情,所以 GNSO 是决定替换这项要求与否的主管机构。

      这项决定的财务影响是什么?

      这项决定对 ICANN 没有任何财务影响。对于那些选择不保留商业综合责任险的注册服务机构和潜在注册服务机构来说,取消这项要求可以降低他们的成本。

      这项决定对社群有哪些影响?

      根据迄今收到的所有信息,如果董事会批准免除这一保险要求,则并不会对注册人、其他利益相关方或全球公益造成负面影响。

      与此同时,这项决定将会对潜在注册服务机构和现有注册服务机构产生积极影响,对于那些位于 CGL 保险过于昂贵或没有这种保险的地区中的注册服务机构来说,情况更是如此。说到影响,可能主要是财务方面的影响,但这会鼓励发达国家/地区和发展中国家/地区出现更多申请注册服务机构认证的情况。

      董事会批准免除这项保险要求将有助于加强 ICANN 在全球环境中促进注册服务机构竞争的工作,并为 GNSO 提供机会来考虑是否适合替换保险要求。

      对互联网的安全性和稳定性有哪些影响?

      批准这项决议将不会对与 DNS 有关的安全性、稳定性和灵活性问题产生影响。

    6. GNSO 政策和实施建议

      Bruce Tonkin 介绍了这个会议议项。起因于 GNSO 指导流程 (GGP) 和 GNSO 快速政策制定流程 (EPDP),董事会收到了一系列来自 GNSO 非 PDP 政策和实施工作组《最终建议报告》中的建议,这些建议提出修订有关处理新 GNSO 投票表决阈值的章程。董事会已针对所提议的章程修订征询了公众意见,并在公共评议期间收到了两条意见。有人要求董事会通过批准章程修订(已进行了公众意见征询),采纳并实施 GNSO 关于该项政策的建议。另外,董事会还批准了所提议的 GNSO 政策、实施原则和指南,以指导涉及 GNSO 政策和实施的员工和社群进行工作。董事会还进一步认可了 ALAC 提出的建议,并承诺会密切监督 GNSO 政策制定活动,以确保用户和公共利益得到适当考虑。

      Bruce 提出决议并得到主席的支持,董事会接下来采取了以下行动:

      2013 年 7 月 17 日,GNSO 理事会批准了 GNSO 非 PDP 政策和实施工作组章程 (http://gnso.icann.org/en/council/resolutions#201307),目的是向 GNSO 理事会提供一系列有关以下内容的建议:

      • 一组原则,支持在考虑现有 GNSO 运营规程的情况下,进行任何与 GNSO 政策和实施有关的讨论。
      • 一个可能以"政策指南"的形式制定通用顶级域政策的流程,包括有关什么时候适合使用此流程(用于制定除"共识性政策"之外的政策),而不使用 GNSO 政策制定流程的判断标准。
      • 一个与实施和 GNSO 政策建议相关的讨论框架。
      • 用于确定何时应通过政策流程采取措施,以及何时应考虑实施的标准。
      • 根据《PDP 手册》中的定义,关于预计 GNSO 实施审核小组如何发挥职能和运营的进一步指南。

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

      GNSO 政策和实施工作组审核了收到的意见和建议(请参阅公众意见审核工具),并相应地更新了报告,从而于 2015 年 6 月 2 日向 GNSO 理事会提交了最终建议报告。

      最终建议报告(请参阅 http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf)于 2015 年 6 月 24 日经全体同意被 GNSO 理事会采纳。

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

      收到两条支持所提建议的评论,其中包括一项来自 ALAC 的建议声明。

      ATRT2 建议"董事会应继续支持跨社群合作,目的在于推进对政策制定和政策实施之间差异情况的了解。凭借支持组织和咨询委员会 (SO/AC) 在制定补偿机制时可以向董事会咨询相关事宜,包括但不限于政策、实施和管理事宜,对于这些事宜应由董事会做出决策"(建议 4)。

      已决定(第 2015.09.28.16 号决议),董事会在征询了公众意见后批准了对 ICANN 章程第 X 条第 3-9 节的修订意见,这些修订意见涉及处理由 GNSO 指导流程 (GGP) 和 GNSO 快速政策制定流程 (EPDP) 引起的新 GNSO 投票表决阈值。

      已决定(第 2105.09.28.17 号决议),董事会在征询了公众意见后批准了对 ICANN 章程附录 A 的修订意见(请参阅 https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf),从而制定了一个新的附录 A-1,其中概述了 GNSO EPDP。

      已决定(第 2015.09.28.18 号决议),董事会在征询了公众意见后批准了对 ICANN 章程附录 A 的修订意见(请参阅 https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf),从而制定了一个新的附录 A-2,其中概述了 GNSO GGP。

      已决定(第 2015.09.28.19 号决议),董事会批准了一系列 GNSO 原则/要求,因为根据《最终建议报告》中第 4 节的内容,这些原则/要求与政策和实施有关,并指示总裁和 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 社群和其他参与机构为这项工作付出的辛勤努力。

      在所有出席会议的董事会成员中,共有 14 位成员投票赞成第 2015.09.28.16 号、第 2015.09.28.17 号、第 2015.09.28.18 号、第 2015.09.28.19 号、第 2015.09.28.20 号、第 2015.09.28.21 号、第 2015.09.28.22 号、第 2015.09.28.23 号和第 2015.09.28.24 号决议。Ray Plzak 投了弃权票。Erika Mann 无法针对这些决议进行投票。决议通过

      第 2015.09.28.16 - 2015.09.28.24 号决议的理由

      为何董事会要解决此问题?

      在讨论如何推行与新通用顶级域名 (gTLD) 项目相关的事务过程中,人们越来越关注:哪些话题与政策相关,哪些话题与实施工作相关,具体情况包括:应当使用哪些流程?如果在实施过程中出现了不同意见,应当何时并通过什么方式来采取行动?经过几次讨论(包括公布工作人员讨论文件和在 ICANN 第 46 届会议期间进行的社群会议),通用名称支持组织 (GNSO) 理事会于 2013 年 7 月决定成立一个工作组 (WG),负责制定关于以下内容的建议:

      • 一组原则,支持在考虑现有 GNSO 运营规程的情况下,进行未来与 GNSO 政策和实施有关的讨论。
      • 一个可能以"政策指南"的形式制定通用顶级域政策的流程,包括有关什么时候适合使用此流程(用于制定除"共识性政策"之外的政策),而不使用 GNSO 政策制定流程的判断标准。
      • 一个与实施和 GNSO 政策建议相关的讨论框架。
      • 用于确定何时应通过政策流程采取措施,以及何时应考虑实施的标准;同时,
      • 根据《PDP 手册》中的定义,关于预计 GNSO 实施审核小组如何发挥职能和运营的进一步指南。

      工作组提出的这些建议已于 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.pdfhttp://forum.icann.org/lists/comments-policy-implementation-31jan13/)以及在 ICANN 第 46 届会议期间召开的社群会议(请参阅 http://beijing46.icann.org/node/37133),通用名称支持组织 (GNSO) 理事会在与其他 SO/AC 协商后(请参阅 http://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf),于 2013 年 7 月决定成立一个 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)及相关材料。

      董事会认为至关重要的因素有哪些?会对社群产生积极还是消极的影响?

      董事会认为,社群在提出这些建议时应与 ICANN 员工进行协商,并且这些建议需要得到 GNSO 理事会的一致支持,这两点因素至关重要。同时,董事会还意识到处理这个问题的重要性,就像 ATRT2 所指出的那样,董事会认为这些建议将为 GNSO 理事会提供更多的灵活性,让他们能够通过正式的流程,以及通过针对有关 GNSO 政策和实施的问题进行必要的澄清和预测,来处理政策问题。

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

      实施这些建议预计不会造成财务方面的影响或产生分歧。

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

      尚未发现实施这些建议会造成任何与 DNS 有关的安全性、稳定性或灵活性问题。

    7. 委任 2016 年提名委员会主席和候选主席 – 执行会议

      董事会召开了一次机密会议。会议期间,董事会执行了以下工作

      BGC 审核了候选人提交的用来参选 2016 年提名委员会 (NomCom) 主席和候任主席的《意向表述书》,考虑了对 2015 年 NomCom 领导层进行的 360 度评估的结果,并对候选人进行了面试。

      BGC 推荐任命 Stéphane Van Gelder 为 2016 年 NomCom 主席,推荐任命 Hans Petter Holen 为 2016 年 NomCom 候任主席。

      已决定(第 2015.09.28.25 号决议),董事会特此任命 Stéphane Van Gelder 为 2016 年提名委员会主席,任命 Hans Petter Holen 为 2016 年提名委员会候任主席。

      第 2015.09.28.25 号决议的理由

      ICANN 章程要求由董事会任命提名委员会 (NomCom) 主席和 NomCom 候任主席。请参阅位于 http://www.icann.org/en/general/bylaws.htm - VII 的第 VII 条第 2.1 节和第 2.2 节。董事会已授权董事会治理委员会负责推荐 NomCom 主席和候任主席,以供董事会审批。请参阅位于 http://www.icann.org/en/committees/board-governance/charter.htm 的 BGC 章程。BGC 于 2015 年 6 月 4 日发布了一则《意向表述书》(EOI) 征询公告,于 2015 年 6 月 30 日之前征询 EOI(请参阅 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 领导层进行的 360 度评估,并在起草推荐内容之前对候选人进行了面试。董事会对 BGC 提出的有关 2016 年 NomCom 主席和 2016 年 NomCom 候任主席的推荐人选进行了审核,并且表示同意。另外,董事会也向有志成为 2016 年 NomCom 领导层的所有人员表示感谢。

      这种采用公开的 EOI 流程来任命 NomCom 主席和候任主席,会对 ICANN 的透明度和问责制产生积极影响,同时还可以支持公众利益。采纳 BGC 的建议并没有对 ICANN 产生以其他方式没有预料到的财务影响,并且不会对域名系统的安全性、稳定性和灵活性产生负面影响。

    • 随后主席宣布会议结束。

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

2 另请参阅 5.1.1 和公众意见审查工具(位于《最终报告》的附录 B)。

3 很多人认为这将是英文 US-ASCII,尽管支持其他文字的理由令人信服。

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

minutes-28sep15-zh.pdf  [453 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."