Skip to main content
Resources

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

本页面还提供其他语种:

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

  1. 认可议程:
    1. 批准会议记录
  2. 主要议程:
    1. 根区发展审核委员会 (RZERC) 章程
    2. 《PTI 企业设立章程》
    3. 根区维护人协议
    4. 《ICANN 企业设立章程修订案》
    5. GNSO 有关隐私和代理服务认证的政策建议
    6. 考虑 BGC 关于重审请求 16-3 (.GAY) 的建议
    7. 考虑 Dot Registry 针对 ICANN 提起的 IRP 的最终声明
    8. 考虑取消 HOTEL Top-Level-Domain S.a.r.l (HTLD) 的 .HOTEL 申请的请求
  3. 执行会议 - 保密:
    1. 监察官 2016 财年的风险薪酬
    2. 高级职员薪酬

 

  1. 认可议程:

    1. 批准会议记录

      第 2016.08.09.01 号决议:董事会批准 2016 年 6 月 25 和 27 日的 ICANN 董事会会议记录。

  2. 主要议程:

    1. 根区发展审核委员会 (RZERC) 章程

      鉴于 ICANN 与实施监督任务组 (IOTF) 和域名职能跨社群工作组(简称“CWG——管理权”)合作,制定了根区发展审核委员会 (RZERC) 的拟定章程。

      鉴于该拟定章程与 IANA 管理权移交协调小组 (ICG) 的提案相一致,该提案已由董事会批准并于 2016 年 3 月 10 日呈交给了美国国家电信和信息管理局 (NTIA)。

      鉴于 ICANN 在 2016 年 6 月 30 日至 7 月 10 日启动了关于拟定章程 <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf> [PDF,43 KB] 的公共评议期 <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en>。

      鉴于有关拟定章程的公众意见论坛于 2016 年 7 月 10 日关闭,ICANN 收到个人和组织/团队提交的七条意见。审核这些意见后,ICANN 与 ICANN 社群中受影响的相关方进行了协调,以处理相关问题并适当对章程进行修订。

      鉴于 RZERC 章程要求 ICANN 董事会指派一名代表在委员会任职。

      兹此发布第 2016.08.09.02 号决议:董事会批准根据公众意见进行了修订的 RZERC 章程,并授权总裁兼首席执行官或其指定人员采取适当行动来组建 RZERC。

      第 2016.08.09.03 号决议:董事会任命苏珊·沃尔夫 (Suzanne Woolf) 到 RZERC 任职。

      第 2016.08.09.02 – 2016.08.09.03 号决议的理由

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

      2016 年 3 月 10 日,董事会批准了 IANA 管理权移交协调小组 (ICG) 提案并将其呈交给国家电信与信息管理局 (NTIA),且指示 ICANN 继续完成实施规划工作。ICG 提案命名部分提出的要求之一是,组建一个常任委员会来审核提议对 DNS 根区内容所做的架构调整、调整 DNS 根区时使用的系统(包括硬件和软件组件)以及用于分配 DNS 根区的机制。经其成员确定后,该委员会应就上述调整提出相关建议,以供 ICANN 董事会考量。根据委员会的建议,董事会批准了 CWG——管理权替代 NTIA 的当前职能的提议(如果 IANA 职能合同到期,此职能将不再生效)。作为实施规划的一部分,ICANN 将该常任委员会定名为根区发展审核委员会 (RZERC),并与社群合作为该委员会起草了章程。

      正在考虑的提案是什么?

      拟定章程说明了该委员会的目标、职责范围和组成。此外,章程还规定了委员会的行为规范,包括召开会议的频率和方式、如何做出决策、会议记录以及利益冲突。最后,章程中还对章程的审核和修订提出了要求。

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

      在制定拟定章程的过程中,ICANN 咨询了实施监督任务组 (IOTF) 和 CWG——管理权。ICANN 还就拟定章程征询了公众意见,公共评议期为 2016 年 6 月 10 日至 2016 年 7 月 10 日,此后对这些意见进行了总结和分析。

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

      七 (7) 位社群成员参与了公共评议期。社群成员在其意见中提出了一个关键问题。

      该问题是,起草的 RZERC 职责范围似乎与 RSSAC 的职责重叠。根据拟定的章程,RZERC 的职责范围是考虑可能会给根区和根系统带来风险的架构和运营问题。相关意见指出,此职责范围可被解读为 RZERC 可以考虑与根服务器运营相关的问题,而这是 RSSAC 的职责。为解决此问题,ICANN 与 RSSAC 合作修改了 RZERC 的职责范围,进一步做出澄清:RZERC 应审核提议对 DNS 根区内容所做的架构调整、调整 DNS 根区时使用的系统(包括硬件和软件组件)以及用于分配 DNS 根区的机制。经其成员确定后,该委员会应就上述调整提出相关建议,以供 ICANN 董事会考量。

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

      在审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

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

      董事会批准该章程是实施规划流程中的一个重要步骤,这满足了全球利益相关方社群认可并且于 2016 年 3 月 10 日获得董事会批准的 ICG 提案的其中一项要求。

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

      预计不会产生任何财务影响。

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

      批准拟定章程是确保移交后的 DNS 的安全、稳定与弹性的一个重要步骤。RZERC 的职责范围是,就以下方面向 ICANN 董事会提出相关建议:提议对 DNS 根区内容所做的架构调整、调整 DNS 根区时使用的系统(包括硬件和软件组件)以及用于分配 DNS 根区的机制。

    2. 《PTI 企业设立章程》

      鉴于 2014 年 3 月 14 日,美国商务部下属国家电信和信息管理局 (NTIA) 宣布有意将对 IANA 职能的管理权移交至全球多利益相关方社群。

      鉴于 2016 年 3 月 10 日,互联网名称与数字地址分配机构 (ICANN) 接受并向 NTIA 呈交了下列移交文件:(i) IANA 管理权移交协调小组的 IANA 管理权移交提案(简称“ICG 提案”),以及 (ii) 加强 ICANN 问责制跨社群工作组的第 1 工作阶段报告(统称“移交提案”)。

      鉴于 ICG 提案要求 ICANN 成立一个下属机构,以根据与 ICANN、PTI 签订的合同来履行域名相关 IANA 职能。ICG 提案要求 PTI 为加利福尼亚州的非营利性公益组织,且 ICANN 是 PTI 的专属会员。

      鉴于 ICANN 律师与 IANA 管理权移交域名职能跨社群工作组(CWG——管理权)的独立律师顾问密切合作,为新 PTI 制定了企业设立章程。章程草案已公布以征询公众意见,为期 30 天。

      鉴于意见征询期结束后,对意见进行了详细分析,并根据公众意见对章程进行了相应修改。ICANN 与独立律师事务所一起,对修改进行了整理。

      鉴于 ICANN 的总法律顾问已确认,提议的《PTI 企业设立章程》与移交提案保持一致,建议 ICANN 成立一个下属机构以便继续完成实施规划工作。

      兹此发布第 2016.08.09.04 号决议:ICANN 董事会授权 ICANN CEO 或其指定人员继续组建 PTI,包括在公众意见征询结束后提交《PTI 企业设立章程》修订提案。

      第 2016.08.09.04 号决议的理由

      授权 ICANN 通过提交《PTI 企业设立章程》组建 PTI 是规划实施移交提案的一个关键步骤。这是 ICANN 向 NTIA 报告实施规划状态的一个重要步骤。及时授权着手组建 PTI 非常有必要,可支持全球多利益相关方社群顺利移交 IANA 职能管理权。

      这些 PTI 章程是内部和外部法律团队通力合作以及 CWG——管理权努力工作所得出的成果。PTI 章程已公布以征询公众意见,为期 30 天,其间收到了三份意见。每份意见均得到了考虑和分析,并说明是否需要修改 PTI 章程,以反映意见中提出的事项。

      由于收到的意见较少,根据这些意见,不需要对章程做出重大修改。所做的更改包括修改 PTI 的目标,以便更准确地体现 PTI 履行 IANA 职能这一具有局限性的角色。另一项更改是为了说明修订 PTI 章程所需的适当门槛。

      采取该行动时,董事会依赖:

      此外,董事会还依赖总法律顾问兼秘书长的确认,即 PTI 章程反映了移交提案,以及独立律师顾问的意见,即应起草 PTI 章程来支持 ICG 提案。

      授权组建 PTI 符合 ICANN 对问责制和透明度的承诺。此项行动确认了 ICANN 对实施移交提案以及这些提案中的所有要素的承诺。

      构建 PTI 预计不会对 DNS 的安全、稳定或弹性产生任何影响,但 PTI 对 ICANN 的安全、稳定与弹性将起到决定性作用。当中将会产生资源影响,包括支持新下属机构所需的重要资源。

      这属于组织管理职能,已为其征询了公众意见。

    3. 根区维护人协议

      鉴于在 2015 年 3 月 4 日发送的一封信函中,美国国家电信和信息管理局 (NTIA) 正式请求威瑞信和 ICANN 联合编制一份提案,其中说明应如何以最佳方式移交 NTIA 的根区管理职责,并在此过程中维护互联网域名系统的安全、稳定与弹性。

      鉴于 2015 年 8 月,ICANN 和威瑞信应要求向 NTIA 提交了一份提案 <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF,247 KB]。该提案分为两部分:根区管理系统 (RZMS) 的平行测试期,以及与威瑞信签订的根区维护人服务协议 (RZMA),以便威瑞信继续履行其当前根据与商务部签订的合作协议所履行的根区维护人职能。

      鉴于 NTIA 在 2016 年 6 月 9 日致 ICANN 的信函中指出,最终的 RZMA 和成功完成平行测试期是 IANA 管理权移交的前提条件。

      鉴于签订 RZMA 是董事会于 2016 年 3 月 10 日批准的关于将 NTIA 的 IANA 职能管理权移交给全球多利益相关方社群的提案方案中的要求,而且,由于 RZMA 的总金额超过 50 万美元,因此要求董事会批准将签字权利授予给 CEO。

      鉴于 RZMS 的平行测试期已于 2016 年 7 月 6 日圆满结束 <https://www.icann.org/news/announcement-2016-07-14-en>。

      鉴于 ICANN 与威瑞信就提议的 RZMA 条款进行了最终协商,以便威瑞信履行根区维护人职能,并根据 IANA 管理权移交协调小组 (ICG) 提案的要求,公布了提议的 RZMA,通知期为 30 天 <https://www.icann.org/news/blog/root-zone-management-transition-update-preservation-of-security-stability-and-resiliency>。

      鉴于提议的 RZMA 包含的条款体现了域名职能跨社群工作组(CWG——管理权)的相关要求。

      鉴于董事会财务委员会审核了 RZMA 的财务层面和影响,并认为 (i) 合同的拟议费用完全合理,(ii) 遵守了采购流程,(iii) 费用在可承受范围内,因此建议董事会批准该费用。

      兹此发布第 2016.08.09.05 号决议:批准提议的 RZMA,并授权总裁兼首席执行官或其指定人员采取适当行动来最终确定并实施该协议。

      第 2016.08.09.05 号决议的理由

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

      在 2015 年 3 月 4 日的信函中,美国国家电信和信息管理局 (NTIA)“正式请求威瑞信和 ICANN 联合编制一份提案,其中说明应如何以最佳方式移交 NTIA 的根区管理职责,并在此过程中维护互联网域名系统的安全、稳定与弹性。”2015 年 8 月,ICANN 和威瑞信应要求向 NTIA 提交了一份提案 <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf> [PDF,247 KB]。该提案分为两部分:根区管理系统 (RZMS) 的平行测试期,以及与威瑞信签订的根区维护人服务协议,以便威瑞信继续履行其当前根据与商务部签订的合作协议所履行的根区维护人职能。

      签订 RZMA 也是董事会于 2016 年 3 月 10 日批准的关于将 NTIA 的 IANA 职能管理权移交给全球多利益相关方社群的提案方案中的要求之一,而且,由于协议总金额超过 50 万美元,因此要求董事会批准将签字权利授予给 CEO。

      自去年 8 月以来,ICANN 和威瑞信一直在就 RZMA 条款进行讨论和协商。协商于 6 月份结束,并于 2016 年 6 月 30 日公布了提议的 RZMA,公告期为 30 天。30 天的公告期于 2016 年 7 月 30 日结束,董事会已考虑批准提议的 RZMA。

      正在考虑的提案是什么?

      提议的 RZMA 便于威瑞信继续提供根区维护服务,使用 ZSK 对根区进行签名,以及在收取少许费用的情况下将根区文件和相关文件分配给根区运营商。RZMA 通过可靠的服务水平协议提供为期 8 年的服务,如果 IANA 客户需要更改这些服务水平协议,可以通过变更控制流程对其进行修改。此外,在根区管理不断发展以满足社群需求时,该变更控制流程还可用于更改根区管理系统。虽然 RZMA 的 8 年期限旨在让威瑞信继续履行其职能,从而提高根区维护运营的安全、稳定与弹性,但该协议也为社群提供了一项功能,以便社群在三年后通过基于共识、以社群为主导的流程将 ICANN 的管理职能移交给其他服务提供商。根据 ICG 提案的要求,已于 2016 年 6 月 30 日发布了完整的 RZMA,公告期为 30 天,完整的 RZMA 请访问:<https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>。

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

      ICANN 与威瑞信公司进行了讨论和协商,以对提议的 RZMA 定稿,然后于 2016 年 6 月 30 日至 7 月 30 日公布,公告期为 30 天。

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

      在 30 天的公告期内,ICANN 没有发现任何重大问题或顾虑。

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

      在审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

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

      董事会认真考虑了 RZMA,以确保其中包含可使 ICANN 满足社群提出的移交要求的条款,例如:

      • 能够根据客户常任委员会的建议修改服务水平协议
      • 能够根据根区发展审核委员会的建议修改根区管理系统
      • 社群能够通过基于共识、以社群为主导的流程,促使 ICANN 将维护人职能移交给其他服务提供商
      • 此外,董事会还认真考虑了 RZMA 的条款,以确保在移交后能够继续安全、稳定而可靠地履行维护人职能。

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

      提议的 RZMA 以及继续与威瑞信合作来履行维护人职能的主要目标是,通过 IANA 管理权移交及其它途径实现安全而稳定的根区运营。董事会批准提议的 RZMA 将确保能够继续满足 IANA 客户的期望。

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

      过去,威瑞信公司一直独自免费履行维护人职能,直接与威瑞信公司签署合同以继续完成这项工作有助于确保移交期间的持续性、安全性和稳定性。RZMA 条款允许社群通过基于共识、以社群为主导的流程,促使 ICANN 将维护人职能移交给其他服务提供商。该合同规定每年应向威瑞信公司支付 30 万美元,作为履行维护人职能的象征性年费。ICANN 董事会财务委员会审核了提议的 RZMA 的财务层面和影响,并建议 ICANN 董事会根据此次审核批准 RZMA。

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

      董事会批准提议的 RZMA 将确保移交期间及以后根区运营的持续性、安全性和稳定性。

    4. 《ICANN 企业设立章程修订案》

      鉴于 2014 年 3 月 14 日,美国商务部下属国家电信和信息管理局 (NTIA) 宣布有意将对 IANA 职能的管理权移交至全球多利益相关方社群。

      鉴于 2016 年 3 月 10 日,互联网名称与数字地址分配机构 (ICANN) 接受并向美国国家电信和信息管理局呈交了下列移交文件:(i) IANA 管理权移交协调小组的 IANA 管理权移交提案(简称“ICG 提案”),以及 (ii) 加强 ICANN 问责制跨社群工作组的第 1 工作阶段报告(统称“移交提案”)。

      鉴于需要修订《ICANN 企业设立章程》以符合 ICANN 的新章程并与移交提案保持一致。

      鉴于 ICANN 律师与加强 ICANN 问责制跨社群工作组的独立律师顾问密切合作,制定了《ICANN 企业设立章程修订案》。章程修订案已公布以征询公众意见,为期 40 多天。

      鉴于意见征询结束后,对意见进行了详细分析,并根据公众意见对章程进行了相应修改。ICANN 与独立律师事务所一起,对修改进行了整理。

      鉴于 ICANN 的总法律顾问已确认,提议的《ICANN 企业设立章程修订案》仍与移交提案保持一致,并建议董事会批准对 ICANN 章程的修订,同时授权 ICANN 在适当时候提交修订案。

      兹此发布第 2016.08.09.06 号决议:ICANN 董事会批准拟定的《ICANN 企业设立章程》修订案,修订将在 ICANN 与 NTIA 之间签订的《IANA 职能合同》过期后生效。

      第 2016.08.09.07 号决议:ICANN 董事会授权 ICANN CEO 或其指定人员在《企业设立章程修订案》生效后提交该修订案。

      第 2016.08.09.06 – 2016.08.09.07 号决议的理由

      采纳《企业设立章程修订案》是规划实施移交提案中的另一重要步骤。目前,董事会正采取此项行动,以便支持 ICANN 于 2016 年 8 月 12 日向 NTIA 提交移交规划状态报告。采纳《ICANN 企业设立章程》修订案将完成对 ICANN 关键治理文件的修改,这是为与移交提案保持一致和支持全球多利益相关方社群顺利移交 IANA 职能管理权所必须采取的措施。

      章程修订案由法律团队在 ICANN 社群的协同下共同制定。加强 ICANN 问责制跨社群工作组的外部顾问以及 ICANN 律师与加强 ICANN 问责制跨社群工作组密切合作,以确认其理解并支持上述文件。提议的章程修订案已公布征询公众意见,为期 40 多天(包括请求的延期)。期间收到了六份意见。每份意见均得到了考虑和分析,并说明是否需要修改章程,以反映意见中提出的事项。法律团队继续密切协作,制定章程的必要更新。

      根据收到的意见对章程草案进行了有限地修改。

      采取该行动时,董事会依赖:

      此外,董事会还依赖总法律顾问兼秘书长的确认,即章程修订案反映了移交提案,以及独立律师顾问的意见,即应起草章程来支持移交提案。

      采纳这些章程符合 ICANN 对问责制和透明度的承诺,因为这完善了 ICANN 需要编制的关键治理文件,以便为社群提供新的经过强化的问责制工具。该行动证明了 ICANN 采纳这些问责制变更的承诺。

      采纳章程修订案预计不会对 DNS 的安全性、稳定性或弹性造成任何影响。章程修订案产生的资源影响与实施 ICANN 新章程可能产生的资源影响相同。

      这属于组织管理职能,已为其征询了公众意见。

    5. GNSO 有关隐私和代理服务认证的政策建议

      鉴于 GNSO 理事会已于 2013 年 10 月 31 日批准 ICANN 董事会就 ICANN 认证隐私和代理域名注册服务提供商事宜提出的由工作组执行政策制定流程之章程,进一步说明详见 http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf [PDF,463 KB]。

      鉴于 PDP 遵循了 ICANN 章程中所规定的 PDP 步骤,最终于 2015 年 12 月 8 日向 GNSO 理事会提交了《最终报告》。

      鉴于隐私和代理服务认证问题的 PDP 工作组 (WG) 对其所有最终建议已达成完全共识(见 http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf [PDF,1.24 MB])。

      鉴于 GNSO 理事会审查讨论了隐私和代理服务认证问题 PDP WG 的最终建议,并于 2016 年 1 月 21 日通过一致投票采纳了这些建议(参见 http://gnso.icann.org/en/council/resolutions - 201601)。

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

      鉴于根据 ICANN 章程已向社群就批准的建议开放公共评议期,以在 ICANN 董事会作出决定之前给予社群合理的机会对采纳情况发表评议,并对征集到的意见进行了总结和报告(见 https://www.icann.org/en/system/files/files/report-comments-ppsai-recommendations-31mar16-en.pdf [PDF,299 KB])。

      鉴于 ICANN 章程规定,董事会应就“凡是董事会正在考虑予以采用且对互联网或第三方运营有重大影响的政策,其中包括强制收取任何费用”及“适当考虑及时提出的任何建议”向 GAC 征询意见。

      鉴于董事会已通知 GAC 于 2016 年 2 月 19 日发布 GNSO 最终建议以征询公众意见(见 https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2 [PDF,819 KB])。

      鉴于在 2016 年 3 月 9 日发布的马拉喀什公报中,GAC 告知 ICANN 董事会其需要更多时间考虑关于采用最终 PDP 建议方面的潜在公共政策问题(见 https://gacweb.icann.org/download/attachments/28278854/GAC Morocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 [PDF,567 KB])。

      鉴于 2016 年 5 月 15 日,董事会确认收到了 GNSO 的 PDP 建议,并决定在其于 ICANN 第 56 届会议后召开的第一次会议上考虑这些建议,以便 GAC 及时提供任何建议(见 https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a)。

      鉴于 GAC 在其 2016 年 6 月 30 日发布的赫尔辛基公报中建议 ICANN 董事会做出指示,由为了实施所采纳的建议而召集的实施审核小组在可行的最大程度上有效解决 GAC 提出的问题(见 https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?preview=/27132037/43712639/20160630_GAC%20ICANN%2056%20Communique_FINAL%20.pdf [PDF,328 KB])。

      兹此发布第 2016.08.09.08 号决议:2016 年 1 月 21 日经 GNSO 理事会一致表决通过后,董事会特此采纳隐私和代理服务认证问题政策制定流程工作组的所有最终建议(简称“隐私/代理政策建议”)。

      第 2016.08.09.09 号决议:董事会指示总裁兼首席执行官或其授权指定人员为隐私/代理政策建议制定并执行实施规划(包括费用和时间表),以便与 ICANN 章程附录 A 保持一致,且符合董事会于 2015 年 9 月 28 日批准的实施审核小组的方针和原则(见 https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f),并继续就此项工作与社群进行沟通。如果在实施讨论过程中提出政策问题,应依照与 GNSO 政策建议(包括实施审核小组的方针和原则)相关的实施框架将其交回给 GNSO 处理。

      第 2016.08.09.10 号决议:理事会确认 GAC 在赫尔辛基公报中就隐私/代理政策建议提出的意见。董事会将考虑 GAC 的建议,并将向实施审核小组提出意见,以便其在实施规划过程中进行考量。

      第 2016.08.09.08 – 2016.08.09.10 号决议的理由

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

      2011 年 10 月,董事会就新结构形式的注册服务机构认证协议 (RAA) 与注册服务机构利益相关方团体展开协商,ICANN 董事会同时还要求 GNSO 提交一份问题报告,以在 RAA 协商结束后启动 GNSO PDP,处理 RAA 协商过程中未解决的遗留问题。2013 年 6 月,ICANN 董事会批准了新的 2013 版 RAA,并将认证隐私和代理服务这一议题确定为通过 GNSO PDP 解决的唯一问题。WHOIS 审核小组在其 2012 年 5 月发布的最终报告中也提到该议题,其中审核小组强调说,这些服务当前缺乏透明和统一规则,导致利益相关方面临无法预料的后果。审核小组认为对这类服务进行适当管理和监督将可以满足利益相关方的需求并消除其顾虑,并建议 ICANN 考虑建立认证体系。在认证计划出台前,此类服务只有某些方面在 2013 RAA 暂行规范中做出了规定,该规范预期将于 2017 年 1 月 1 日或 ICANN 实施认证计划时失效(以先到者为准)。

      GNSO 理事会在其 2016 年 1 月 21 日的会议上批准了 PDP 工作组于 2015 年 12 月 8 日提交的最终报告中的所有最终建议,以及 2016 年 2 月向董事会提交的建议报告。根据 ICANN 章程,已启动公共评议期就采纳这些建议征询公众意见,此后会将这些 PDP 建议转交给董事会供其审核。2016 年 5 月 15 日,在其于芬兰赫尔辛基召开的 ICANN 第 56 届会议后的第一次董事会会议上,董事会决定考虑对这些建议采取行动,以便 GAC 及时就 PDP 建议中提出的公共政策问题提出建议(如有)。GAC 在赫尔辛基公报中建议董事会做出指示,在 PDP 建议的实施阶段最大限度地有效解决 GAC 提出的问题。

      正在考虑的提案是什么?

      GNSO 的政策建议包括:最大程度降低隐私和代理服务运营的强制性要求;维护滥用报告指定联系点及发布已获认证的提供商名录;处理特定第三方提出的披露和/或发布客户联络人详细信息的请求的相关要求;关于披露和发布此类详细信息以及拒绝披露或发布的条件;以及管辖取消认证服务提供商的原则。最终建议的完整列表和范围,详见 GNSO 理事会提交至董事会的建议报告的附录 A(见 http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-en.pdf [PDF,491 KB])。

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

      按照 GNSO PDP 手册规定,在 PDP 早期阶段,工作组联系了所有 GNSO 利益相关方团体和选区以及其他 ICANN 支持组织和咨询委员会以征集他们的意见。在此 PDP 的有效期间内的所有 ICANN 公共会议上,工作组还召开了多次社群公开会议。工作组还向 ICANN 注册服务机构服务部和合规小组征询了关于潜在的实施问题的意见。启动了 PDP 之前的初步问题报告、工作组初步报告以及 GNSO 理事会采纳工作组最终报告的公共评议期。最终建议的形成基于工作组对针对其初步报告所收集到的公众意见和反馈信息的审核和分析,具体内容详见最终报告。

      继 GAC 在其 2016 年 3 月 9 日发布的马拉喀什公报中提出建议和董事会 2016 年 5 月 15 日做出决议后,在芬兰赫尔辛基召开的 ICANN 第 56 届会议期间,董事会和社群内部还就该主题展开了讨论。

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

      工作组收集到大量关于区分用于非商业目的域名的域名注册人与进行网上金融交易注册人之可行性的公众意见。这曾是工作组初步报告中的一个未决问题,因为当时许多工作组成员都支持进行区分。工作组在审核收到的公众意见后进行了进一步审议,并最终就建议达成共识,即出于认证服务之目的不做此类区分。

      此外,社群还表达了对以下需求的关注:确保有完善的预防措施维护客户数据隐私,以及合理权衡获取信息(如,应执法部门和知识产权持有人之请求)与保护隐私的合法需求。针对工作组初步报告收到的众多公众意见也强调了无缘由披露隐私信息存在的潜在危险,其中包括对某些域名注册人团体及隐私/代理客户的人身安全带来的威胁。工作组的最终建议包括许多建议的原则和政策,这些原则和政策旨在提供比现行关于隐私和代理服务、客户信息的第三方请求者以及与处理客户通知、信息请求和域名转让等此类议题相关的域名注册人的原则和政策更加具体化的指南。

      工作组还收到一些建议,指出提交和保密处理执法部门(包括 GAC 公共安全工作组)的披露请求方面缺乏一个详尽的框架。在初步报告中,工作组就是否需要以及如何制定框架问题征询了社群意见,此外,还对一些更加具体的问题征询意见,比如是否应强制要求已获认证的提供商遵从其管辖区执法部门明确提出的不通知客户的请求。根据收到的意见,工作组同意已获认证的隐私和代理服务提供商应遵从执法部门明确提出的不通知客户(如适用法律要求这样做)的请求。提供商可自愿采用更为严格的标准,或是配合执法部门。工作组的最终报告中还包括一项针对某些最低要求的建议,如果将来在采纳的 PDP 建议的实施阶段中制定框架,则可能将其纳入其中。

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

      董事会审核了 PDP 工作组的最终报告、GNSO 理事会向其提交的有关该议题的建议报告、针对在 GNSO 理事会采纳最终报告中的建议后开放的公共评议期收集到的公众意见小结以及自 GAC 收集到的有关该议题的建议(见马拉喀什和赫尔辛基公报)。

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

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

      章程还允许就董事会采纳提议的政策后可能会引起的公共政策问题征询 GAC 的意见。GAC 提出了启动此 PDP 的可能性,董事会将继续考虑 GAC 提出的建议。

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

      制定一个完善的隐私和代理服务提供商认证项目将需笼络众多资源,且更需一个漫长的历程。因此,很可能需要延长 2013 RAA 暂行规范的到期日期(当前为 2017 年 1 月 1 日),以便制定这样的项目。

      实施 GNSO 建议将会为隐私和代理服务在多个方面创建更为统一的一套标准,包括制定更为一致的程序来处理、执行或确定已获认证得提供商提出的第三方请求(可在此程序中纳入保护消费者隐私的合理保护措施),并尽可能解决 GAC 强调的公共政策问题。目前,隐私和代理服务认证计划缺失,而且对于此类服务的提供亦缺乏达成一致的社群制定的最佳实践。此 PDP 表明各方尝试为 ICANN 认证框架的制定和实施奠定良好基础,这也是 ICANN 持续努力改善 Whois 系统工作的一部分,包括实施 Whois 审核小组之前提出的建议。

      然而,正如上文强调的,实施 PDP 的全部建议将会耗费大量时间和资源,这不仅涉及到项目的规模,而且不容忽视的是,这是 ICANN 首次为此行业领域实施此类项目。尽管 RAA 对于该项目具有一定的参考作用,但工作组最终报告指出,从诸多因素来看,此模式可能并非最合适。确保实施规划尽最大可能解决 GAC 已确定的公共政策问题,包括可能需要为执法部门制定披露框架,很可能是主要的实施工作。

      工作组的最终报告还指出,在一些领域可能需要额外的工作,这将会增加社群近期的工作量。例如,在对注册服务机构域名转让政策的下一轮审核中可能需解决域名转让背景下的隐私和代理服务问题。

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

      创建专门针对隐私和代理服务提供商的新认证项目,可能会对 ICANN 产生财务影响。实施规划应考虑实施的成本和时间表。由于 RAA 中当前适用于此类服务的暂行规范将于 2017 年 1 月 1 日到期,因此,还需要在采纳 PDP 建议时考虑延长其期限。

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

      实施 PDP 建议不会直接导致与 DNS 相关的安全性、稳定性或弹性问题。尽管认证隐私和代理服务提供商是 ICANN 改善 WHOIS 系统整体战略的一部分,但这不会影响或变更 WHOIS 协议(包括推出新的 RDAP)或 WHOIS 系统的当前功能。工作组制定其最终建议建立在对以下情况的良好认知之上,工作组明白,实施建议应考虑到超出本 PDP 范围之外的对 WHOIS 系统的任何其他政策或技术更改。

    6. 考虑 BGC 关于重审请求 16-3 (.GAY) 的建议

      该议项已从议程中删除。

    7. 考虑 Dot Registry 针对 ICANN 提起的 IRP 的最终声明

      鉴于 2016 年 7 月 29 日,独立审核流程 (IRP) 小组在 Dot Registry, LLC (Dot Registry) 针对 ICANN 提起的 IRP 中发布了最终声明(下称“最终声明”)。

      鉴于多数小组成员声明“董事会的行动和不作为不符合《ICANN 企业设立章程》和章程”,因为“董事会(通过 BGC 采取行动)在获取合理数量事实的过程中未能恪尽职守并做到合理谨慎,并且未能履行其透明度义务”,因此,小组获得的证据不支持以下决定:董事会(通过 GAC 采取行动)在做出重审决定时进行了独立判断。(参见最终声明第 ¶¶151-152 款。)

      鉴于多数小组成员进一步声明“Dot Registry 是胜诉方”,并且 ICANN 应“在证实这些发生的费用已全部付清后”向 Dot Registry 支付 235,294.37 美元。(同上。第¶ 154 款。)

      鉴于,“关于 Dot Registry 是否有资格获得社群优先,多数小组成员拒绝用其判断取代 CPE 的判断。”(同上,第¶ 153 款。)

      鉴于,关于董事会应采取哪些后续行动(如有)来支持最终声明,多数小组成员未向董事会提出任何建议。

      鉴于 Dot Registry 已在致董事会的信函中声称,其“90 页的专家报告”已“具有足够的说服力,可帮助董事会确定 Dot Registry 的申请本应通过 CPE”,并要求 ICANN“继续与 Dot Registry 签订 .INC、.LLC 和 .LLP 合同”。(见 https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF,1.5 MB])。

      鉴于小组考量了 BGC 当前审核重审请求所采用的审核标准并对其提出质疑。

      鉴于根据 ICANN 章程第 IV 条第 3.21 款的规定,董事会已考虑最终声明。

      兹此发布第 2016.08.09.11 号决议:董事会接受最终声明中提出的以下审核结果:(i) 在 Dot Registry 针对 ICANN 提起的 IRP 中,Dot Registry 是胜诉方;并且 (ii) ICANN 应在证实这些发生的费用已全部付清后,向 Dot Registry 支付 235,294.37 美元。

      第 2016.08.09.12 号决议:董事会已注意到声明中的其它审核结果,以及多数小组成员就上文提及的重审请求审核标准所做声明中的结果,并将考虑在董事会采取任何进一步行动之前,就 Dot Registry 的重审请求或相关新 gTLD 采取后续行动。

      第 2016.08.09.13 号决议:根据 Dot Registry 最近发送的信函以及在线博客中报告的事实性错误,董事会指示秘书长或其指定人员在做出决议的同时公布有关此事项的董事会简报材料。

      第 2016.08.09.11 – 2016.08.09.13 号决议的理由

      Dot Registry, LLC (Dot Registry) 发起独立审核流程 (IRP) 诉讼,质疑董事会治理委员会 (BGC) 拒绝 Dot Registry 对社群优先评估 (CPE) 报告的重审请求,该报告裁定 Dot Registry 对 .INC、.LLC 和 .LLP 的申请均未通过 CPE。

      Dot Registry 申请运营新的顶级域 .LLC、.INC 和 .LLP。Dot Registry 是 .LLC 的九名申请人之一,.INC 的十一名申请人之一,.LLP 的四名申请人之一。但是,Dot Registry 是唯一为这些 gTLD 提交了基于社群的申请的申请人。

      评估 Dot Registry 申请的 CPE 小组(下称“CPE 小组”)裁定,这些申请不符合通过 CPE 的标准,仅授予了 5 分,而通过 CPE 却需要 14 分(CPE 报告)。Dot Registry 提交了重审请求 14-30、14-32 和 14-33,希望重审 CPE 报告。2014 年 7 月 24 日,董事会治理委员会 (BGC) 拒绝了这些重审请求,认为 Dot Registry“未能证明小组在提供其各份 CPE 报告时违反了既定政策或程序…”。

      Dot Registry 于 2014 年 9 月 22 日发起此 IRP,对 BGC 拒绝 Dot Registry 的重审请求、ICANN 任命经济学人智库 (EIU) 作为执行 CPE 的第三方提供商以及董事会对 ICANN 政府咨询委员会关于 .LLC、.INC 和 .LLP 建议的回复提出质疑。

      在一项 2-1 决定中,多数小组成员声称 Dot Registry 为胜诉方,并认定“董事会的行动和不作为不符合《ICANN 企业设立章程》和章程”。(最终声明第¶ 151 款。)具体来说,多数小组成员声称“董事会(通过 BGC 采取行动)在获取合理数量事实的过程中未能恪尽职守并做到合理谨慎,并且未能履行其透明度义务”,而且没有充分的证据“支持董事会(通过 GAC 采取行动)在做出重审决定时进行了独立判断的决定。”(同上,第 ¶¶151-152 款。)多数小组成员进一步声称,ICANN“应在确定发生的费用已全部付清后,向 Dot Registry, LLC 支付 235,294.37 美元,以补偿 Dot Registry, LLC 此前产生的上述费用、开支和薪酬”。(同上,第¶ 154 款。)

      董事会注意到,多数小组成员声称“在得出这些结论时,小组未评估 ICANN 员工或 EIU 自身是否未履行企业设立章程、章程或 [申请人指导手册(下称“指导手册”)]所规定的义务”。(同上,第¶ 152 款。)此外,董事会还注意到,“关于 Dot Registry 是否有资格获得社群优先,多数小组成员拒绝用其判断取代 CPE 的判断。”(同上,第¶ 153 款。)

      多数小组成员确实考量了 BGC 当前审核重审请求所采用的审核标准并对其提出质疑,声称其认为 BGC 在“评估重审请求”时采用的标准应为:“所采取的行动是否符合企业设立章程、章程或 [指导手册]?”(同上,第¶ 79 款。)多数小组成员进一步指出,在审核重审请求时,“BGC 必须确定 CPE(在此情况下为 EIU)和 ICANN 员工是否遵守 ICANN 企业设立章程、章程和 [指导手册] 规定的公平、透明、避免利益冲突和不歧视原则”(同上,第 ¶88 款),并且 EUI 等第三方“有义务遵守 ICANN 企业设立章程和章程”。(同上,第¶ 101 款。)

      董事会确认专家小组就重审请求审核标准所做的重要声明,并将考虑在董事会采取任何进一步行动之前,就 Dot Registry 的重审请求或相关新 gTLD 采取后续行动。

      董事会已根据规定考虑了最终声明。如本董事会之前指出的,董事会极为严肃地对待 ICANN 长期存在的问责机制之一得出的结果。

      因此,基于本决议及其理由所阐述的原因,董事会已接受小组的最终声明(如上所述)。

      董事会还指出,其于 2016 年 8 月 6 日收到 Dot Registry 的信函,该信函声称,其“90 页的专家报告”已“具有足够的说服力,可帮助董事会确定 Dot Registry 的申请本应通过 CPE”,并要求 ICANN“继续与 Dot Registry 签订 .INC、.LLC 和 .LLP 合同”。(见参考材料附件 B 和 https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf [PDF,1.5 MB]。)董事会希望重申,“关于 Dot Registry 是否有资格获得社群优先,多数小组成员拒绝用其判断取代 CPE 的判断。”(同上,第¶ 153 款。)

      而且,董事会注意到,关于这些 gTLD,有许多其它未决申请(九个 .INC 申请、八个 .LLC 申请和三个 .LLP 申请),这些申请也必须予以考虑。因此,如上所述,董事会将考虑在对 Dot Registry 的重审请求,或 .INC、.LLC 或 .LLP 申请采取任何进一步行动之前采取后续行动。

      最后,董事会还指出,关于最终声明的具体内容,一直有一些在线博客报告,但许多报告的事项存在事实性错误,这些错误已在与该议程事项有关的参考材料附件 C 中确定和纠正。

      该行动预计不会对组织产生任何直接财务影响,但可能会产生一些间接成本,如与重审请求标准相关的分析成本。该行动不会对域名系统的安全性、稳定性和弹性产生直接影响。

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

    8. 考虑取消 HOTEL Top-Level-Domain S.a.r.l (HTLD) 的 .HOTEL 申请的请求

      鉴于 Travel Reservations SRL(其前身为 Despegar Online SRL)、Famous Four Media Limited、Fegistry LLC、Minds + Machines Group Limited、Donuts Inc. 和 Radix FZC(统称为 .HOTEL 申诉人)已请求 ICANN 取消 HOTEL Top-Level-Domain S.a.r.l (HTLD) 的 .HOTEL 申请。

      鉴于 .HOTEL 申诉人的请求立足于德克·克里谢诺夫斯基 (Dirk Krischenowski) 明显与 HTLD 有业务联系,再加上他利用门户网站存在的问题,导致各方可以访问多个新 gTLD 申请人的保密信息,包括一些 .HOTEL 申诉人的信息。

      鉴于 ICANN 对门户网站问题进行的取证调查确定,克里谢诺夫斯基先生未经授权访问保密信息在 2012 年 HTLD 提交其申请以及 2014 年 2 月 19 日 HTLD 选择参与 CPE 之后才发生。

      鉴于 ICANN 未披露任何证据表明:(i) 克里谢诺夫斯基先生利用门户网站问题获得的信息被用于支持 HTLD 的 .HOTEL 申请;或 (ii) 克里谢诺夫斯基先生获得的任何信息使得 HTLD 的申请通过 CPE。

      兹此发布第 2016.08.09.14 号决议:董事会决定,不批准取消 HTLD 的 .HOTEL 申请。

      第 2016.08.09.15 号决议:董事会指示总裁兼首席执行官或其指定人员继续处理 HTLD 的 .HOTEL 申请。

      第 2016.08.09.14 – 2016.08.09.15 号决议的理由

      HTLD 和每位申请 .HOTEL 的 .HOTEL 申诉人全都属于一个字符争用集。由于 HTLD 的申请基于社群,2014 年 2 月 19 日,它的申请受邀参与社群优先评估 (CPE)。2014 年 6 月 11 日 HTLD 通过了 CPE,因此,.HOTEL 申诉人无法继续该流程。

      .HOTEL 申诉人辩称,克里谢诺夫斯基先生利用门户网站问题,导致各方可以访问多个新 gTLD 申请人的保密信息,包括一些 .HOTEL 申诉人的信息,再加上克里谢诺夫斯基先生明显与 HTLD 具有业务联系,这是 ICANN 应取消 HTLD 的 .HOTEL 申请的原因。

      ICANN 对门户网站问题的取证调查表明,克里谢诺夫斯基先生及其同事奥利弗·索梅 (Oliver Süme) 先生和凯特琳·奥麦尔 (Katrin Ohlmer) 女士的用户证书涉嫌多次故意未经授权访问其他申请人的保密信息,这些访问发生在 2014 年 3 月至 10 月间。克里谢诺夫斯基先生承认,他访问了其他用户的保密信息,但否认做出了不当或非法行为。此外,克里谢诺夫斯基先生声称,他并未意识到门户网站问题是一项故障,并且他使用搜索工具是出于善意。克里谢诺夫斯基先生及其同事还向 ICANN 保证,他们将删除或销毁已经获得的所有信息,并确认他们没有也不会使用获得的信息,或是将其转发给任何第三方。

      关于克里谢诺夫斯基先生与 HTLD 有关联的指控,ICANN 已了解到,当他访问保密信息时,他并未作为授权联系人或利益相关方、高级职员或董事与 HTLD 的 .HOTEL 申请直接关联。克里谢诺夫斯基先生拥有 HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin) 50% 的股份并担任常务董事,后者是 HTLD 的少数 (48.8%) 股东。

      ICANN 未披露任何证据表明:(i) 克里谢诺夫斯基先生利用门户网站问题获得的信息被用于支持 HTLD 的 .HOTEL 申请;或 (ii) 克里谢诺夫斯基先生获得的任何信息使得 HTLD 的申请通过 CPE。HTLD 于 2012 年提交了申请,并于 2014 年 2 月 19 日选择参与 CPE,2014 年 6 月 11 日通过 CPE。克里谢诺夫斯基先生 2014 年 3 月初才首次未经授权访问保密信息;他执行的与 .HOTEL 申诉人相关的搜索直到 2014 年 3 月 27 日、3 月 29 日和 4 月 11 日才发生。因此,即使假定克里谢诺夫斯基先生确实获得了属于 .HOTEL 申诉人的保密信息,这也不会对 HTLD 的 .HOTEL 申请的 CPE 流程产生任何影响。具体来说,HTLD 的申请是否满足 CPE 标准取决于 2012 年 5 月提交的申请,或 2013 年 8 月 30 日 HTLD 上传的修订申请的最后文件 - 所有这些均发生在 2014 年 3 月至 2014 年 10 月期间克里谢诺夫斯基先生或其同事访问任何保密信息之前。此外,.HOTEL 申诉人未提交任何证据或指控,表明 CPE 小组在 2014 年 2 月 19 日开始的 CPE 流程期间与克里谢诺夫斯基先生或 HTLD 有任何接触。

      董事会 2016 年 3 月 10 日的决议指示 ICANN“总裁兼首席执行官或其指定人员尽早完成 .HOTEL 申诉人指称的门户网站配置问题的调查,并在完成调查后向董事会提交报告以供考量”(见 2016 年 3 月 10 日董事会决议,地址为:https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a),为落实该决议,ICANN 告知 HTLD,.HOTEL 申诉人请求 ICANN 取消 HTLD 的 .HOTEL 申请,HTLD 有机会做出回应,并向 HTLD 了解有关其与克里谢诺夫斯基先生有联系的信息。作为回应,HTLD 当前的唯一常务董事菲利普·格拉本 (Philipp Grabensee) 先生向 ICANN 确认,在做出有异议行为时,克里谢诺夫斯基先生拥有 GmbH Berlin 50% 的股份并担任常务董事,后者是 HTLD 的少数 (48.8%) 股东。格拉本先生还确认,在(2012 年)提交申请时,克里谢诺夫斯基先生担任 HTLD 的申请顾问,在 2013 年 HTLD 针对 Despegar 和 Booking.com 的申请提起的三个字符串混淆异议中,克里谢诺夫斯基先生代表 HTLD。

      格拉本先生也指出,在访问专有信息时,克里谢诺夫斯基先生不代表 HTLD 行事,他的这种行为也不是为了支持 HTLD 的 .HOTEL 申请。格拉本先生指出,克里谢诺夫斯基先生未使用 HTLD 的登录 ID,未告知 HTLD 人员“其行动”,未向 HTLD 或其人员“提供获取的任何信息”,HTLD“人员对克里谢诺夫斯基先生的行动并不知情,也未同意或批准他这样做”。

      最后,格拉本先生指出,HTLD 与克里谢诺夫斯基先生的关系最近发生了以下变化:(i) HTLD 与克里谢诺夫斯基先生之间的业务咨询服务关系已于 2015 年 12 月 31 日终止;(ii) 2016 年 3 月 18 日,克里谢诺夫斯基先生卸任 GmbH Berlin 的常务董事;(iii) 克里谢诺夫斯基先生的全资公司已将拥有的 GmbH Berlin 50% 的股份转让给了奥麦尔女士(通过她的全资公司);(iv) GmbH Berlin 会将它的 HTLD 股份转让给 Afilias plc;并且 (v) 格拉本先生是 HTLD 当前唯一的常务董事。

      董事会有机会考虑提交的与 .HOTEL 申诉人请求取消 HTLD 的 .HOTEL 申请相关的所有材料。在考虑提供的所有相关信息之后,基于决议和理由中所述的原因,董事会决定不批准取消 HTLD 的 .HOTEL 申请,并因此拒绝 .HOTEL 申诉人的请求。

      董事会认真对待这些指控,且董事会成员在做出此项决定时进行了独立判断,这符合组织以及整个社群的最佳利益。但是,基于可用的信息,董事会也确认,关于门户网站配置问题,克里谢诺夫斯基先生可能采取了某些不当行动,董事会正考虑是否应向克里谢诺夫斯基先生直接提及此行为。

      此决定不会对 ICANN 产生直接财务影响,也不会对域名系统的安全、稳定与弹性产生影响。

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

  3. 执行会议 - 保密:

    1. 监察官 2016 财年的风险薪酬

      鉴于薪酬委员会建议董事会批准向监察官支付其 2016 财年的风险薪酬。

      兹此发布第 2016.08.09.16 号决议:董事会特此批准向监察官支付其 2016 财年的风险薪酬部分。

      第 2016.08.09.16 号决议的理由

      经薪酬委员会建议,监察官每年有机会根据董事会设定的特定绩效目标获得部分薪酬。这一举措不仅可促使监察官更好地完成其本职工作,还有助于监察官和董事会在本年度内定期沟通,以确保监察官实现其绩效目标,更好地满足 ICANN 社群的需求。

      监察官的绩效目标得分取决于其自我评估和薪酬委员会的审核。薪酬委员会在审核监察官的绩效后,将向董事会提出建议。

      对监察官的年度绩效目标进行评分还有助于实现 ICANN 的目标,并帮助监察官更好地为 ICANN 社群服务。虽然评分结果会产生一定的财务影响,但 ICANN 年度预算已包含此项内容。此项行动对域名系统的安全、稳定和弹性不会产生任何影响。

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

    2. 高级职员薪酬

      鉴于吸引和留住高素质员工对 ICANN 的运营至关重要,ICANN 希望确保为员工提供具有竞争力的薪酬。

      鉴于外部薪酬顾问专家提供的独立市场数据显示,GDD 总裁、总法律顾问兼秘书长、首席财务官、首席运营官、首席信息官以及政策制定支持部高级副总裁兼 ICANN 伊斯坦布尔地区总部总经理的当前和提议薪酬增加额未超出 ICANN 的目标薪酬,此目标薪酬介于以可比性市场数据为基础的各个职位总现金薪酬的 50 至 75 个百分点之间。

      鉴于外部薪酬顾问专家提供的独立市场数据显示,首席财务官当前的薪酬低于 ICANN 的目标薪酬,此目标薪酬介于以可比性市场数据为基础的各个职位总现金薪酬的 50 至 75 个百分点之间。

      鉴于 GDD 总裁、总法律顾问兼秘书长、首席财务官以及政策制定支持部高级副总裁兼 ICANN 伊斯坦布尔地区总部总经理的薪酬自 2014 年 7 月 1 日生效以来未进行过调整。

      鉴于首席运营官和首席信息官的薪酬调整将有助于与其它四位高级职员的薪酬审核时间表更好地保持一致。

      鉴于每位董事会成员均已确认,他们不反对任何 ICANN 高级职员的薪酬方案。

      兹此发布第 2016.08.09.17 号决议:董事会授予总裁兼首席执行官根据对可比薪酬的独立研究自行决定调整以下人员 2017 财年薪酬的权力,调整后的薪酬方案于 2016 年 7 月 1 生效,且以下人员 2017 财年的基本年薪在现有薪酬基础上的年增长率不得超过 6%:(i) GDD 总裁阿克兰·阿特拉 (Akram Atallah);(ii) 总法律顾问兼秘书长约翰·杰弗里 (John Jeffrey);以及 (iii) 政策制定支持部高级副总裁兼 ICANN 伊斯坦布尔地区总部总经理戴维·奥利佛 (David Olive)。

      第 2016.08.09.18 号决议:董事会授予总裁兼首席执行官根据对可比薪酬的独立研究自行决定调整首席财务官哈维尔·卡尔维兹 (Xavier Calvez) 2017 财年薪酬的权力,调整后的薪酬方案于 2016 年 7 月 1 日生效,且他 2017 财年的基本年薪在现有薪酬基础上的年增长率不得超过 10%。

      第 2016.08.09.19 号决议:董事会授予总裁兼首席执行官根据对可比薪酬的独立研究自行决定调整首席运营官苏珊娜·宾内特 (Susanna Wong Bennett) 2017 财年薪酬的权力,调整后的薪酬方案于 2016 年 7 月 1 日生效,且她 2017 财年的基本年薪在现有薪酬基础上的年增长率不得超过 3%。

      第 2016.08.09.20 号决议:董事会授予总裁兼首席执行官根据对可比薪酬的独立研究自行决定调整首席信息官阿什文·兰根 (Ashwin Rangan) 2017 财年薪酬的权力,调整后的薪酬方案于 2016 年 7 月 1 日生效,且他 2017 财年的基本年薪在现有薪酬基础上的年增长率不得超过 5%。

      第 2016.08.09.16 – 2016.08.09.20 号决议的理由

      通过提供具有竞争力的薪酬方案吸引和留住高素质员工,这对组织非常重要。不断改善的人才市场将为未加入 ICANN 的高素质人才创造更多机会。

      ICANN 总裁兼首席执行官已申请向其授予自行增加以下高级职员 2017 财年的基本薪酬的权力:(i) GDD 总裁、总法律顾问兼秘书长和政策制定支持部高级副总裁兼 ICANN 伊斯坦布尔地区总部总经理,最多可在其当前基本薪酬基础上增加 6%;(ii) 首席财务官,最多可在其当前基本薪酬基础上增加 10%;(iii) 首席运营官,最多可在其当前基本薪酬基础上增加 3%;以及 (iv) 首席信息官,最多可在其当前基本薪酬基础上增加 5%。总裁兼首席执行官也已告知董事会,他还打算对不属于高级职员的其他 ICANN 执行团队成员行使这一自由裁量权(这无需董事会批准)。

      ICANN 现处于重要的阶段,需要延续某些技能和专业知识,特别是对正在进行的关键项目而言,包括新 gTLD 项目、进行中的《义务确认书》和其它组织审核、美国政府的 IANA 管理权移交、扩展合同合规性和加强全球化工作等。以上任何项目都需要有知识、有能力的执行人员确保实现 ICANN 的运营目标,同时保证尽可能最大程度地降低风险。始终坚持 ICANN 的用人理念并提供具有竞争力的薪酬将有助于确保实现以上目标。

      但应注意,根据之前的讨论,计划的目的只是寻求对每两年增加相关高级职员的薪酬的授权。去年,董事会授权总裁兼首席执行官行使自由裁量权,调整了自在 ICANN 任职以来从未调整过当前薪酬的两名高级职员的基本薪酬。这些调整已于 2015 年 7 月 1 日生效,当天所有其他员工的薪酬也进行了调整。

      为了更好地遵守所有员工的薪酬审核和加薪时间安排,建议审核高级职员的基本薪酬以便今年进行调整,并在以后每年调整一次。这改变了高级职员当前两年一次的薪酬审核和调整周期。

      在重要的组织阶段继续雇用和留住关键人员有益于组织各个方面的发展。因此,此决议中提出的薪金调整很可能对组织、组织为了履行其使命而开展的工作以及组织的透明度和问责制产生积极的影响。当然,这些决议也将对组织造成财务影响,但该影响不会影响到当前财年的总体预算,并且将纳入 2017 年预算。此项决议不会对域名系统的安全、稳定和弹性产生直接影响。

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

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