Skip to main content
Resources

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

本页面还提供其他语种:

  1. 认可议程:
    1. 批准会议记录
    2. 批准域名注册管理后端应急运行机构 (EBERO) 项目合同
    3. 审议关于访问域名注册数据的 SSAC 公告 (SAC101)
    4. 访问和身份管理软件的合同续约和费用支付
    5. 感谢第 65 届 ICANN 会议的当地主办机构
    6. 感谢第 65 届 ICANN 会议的赞助商
    7. 感谢第 65 届 ICANN 会议的口译员、工作人员以及会议和酒店团队
  2. 主要议程:
    1. 批准 ICANN《2021-2025 财年战略规划》
    2. 转让 .BJ(贝宁)顶级域
    3. 根据《ICANN 章程》第 4 条第 4.6 款的规定批准用于指导执行特定审核的《运营标准》
    4. 通过安全与稳定咨询委员会第二次组织审核的最终报告、可行性评估与实施规划
    5. GNSO 注册服务机构利益相关方团体章程修正案
    6. 其他事务
  3. 执行会议:
    1. 总裁兼首席执行官 2019 财年下半年风险薪酬和 2020 财年目标
    2. 高级职员薪酬

 

  1. 认可议程:

    1. 批准会议记录

      第 2019.06.23.01 号决议:董事会批准 2019 年 5 月 3 日 ICANN 董事会例行会议和 2019 年 5 月 15 日 ICANN 董事会特殊会议的会议记录。

    2. 批准域名注册管理后端应急运行机构 (EBERO) 项目合同

      鉴于 ICANN 组织结合社群设计的新 gTLD 项目开发了域名注册管理后端应急运行机构 (EBERO) 项目,为面临无法执行 5 项关键注册管理机构职能的注册管理运行机构提供临时过户流程。

      鉴于 ICANN 组织于 2011 年 9 月发布了其初始信息征询,且 EBERO 项目自 2013 年 9 月起开始实施。

      鉴于 ICANN 组织于 2018 年 10 月发布了提案征询来确定域名注册管理后端应急运行机构,以满足 EBERO 项目的最新要求。

      鉴于 ICANN 组织对提案征询进行了评估并确定了候选竞买者名单,证明了其有能力支持 EBERO 项目。

      鉴于董事会财务委员会审议了拟议 EBERO 项目合同的成本并建议董事会批准。

      兹此发布第 2019.06.23.02 号决议:董事会授权总裁兼首席执行官或其指定人员,签订多个为期至少 60 个月的合同并进一步支付相关款项,总成本不超过 [协商一致后确定的金额]

      第 2019.06.23.03 号决议:出于谈判目的,该决议中的具体条款应按照《ICANN 章程》第 3 条第 3.5(b) 款的规定进行保密,保密期截至总裁兼首席执行官认为可以发布保密信息为止。

      第 2019.06.23.02 – 2019.06.23.03 号决议的理由

      ICANN 全球域名分部理解,自 2011 年发布初始信息征询以来,这一行业的发展日趋成熟,需要更好地协调现有注册管理运行机构的要求和 EBERO 提供商的能力,提高该流程的效率,同时实现地理多样性。ICANN 组织于 2018 年 10 月 17 日发布了提案征询,以确定一家或多家能够为 EBERO 项目服务的提供商。ICANN 组织有意在拥有 gTLD 注册管理机构数量最多的地区寻找提供商,这些地区包括:亚太地区、欧洲地区和北美地区。

      最终,ICANN 组织指定了几家竞买者,他们对相关工作有着清晰的了解,并具备在相应服务层级履行服务的能力和基础设施。此外,这些提供商对当前行业和 ICANN 多利益相关方模型非常了解。

      采取措施签订合同是在履行 ICANN 的使命,它符合公共利益,能够确保 ICANN 组织使用适合的第三方提供商,并确保以最具成本效益的方式最大程度增加可用资源。该行动将有助于 ICANN 履行确保域名系统的安全、稳定与弹性的使命。

      由于每一个 EBERO 都会产生额外的固定成本,该行动将对组织产生财务影响。EBERO 使 ICANN 组织的可用服务提供商更具地理多样性,同时也让定价模式更具竞争力。目前,ICANN 将在未来五年内支付三家 EBERO 提供商 [协商一致后确定的金额]。通过 RFP 流程选择提供商将节约 30% 左右的成本,同时还可以提高对 EBERO 项目的技术支持水平。

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

    3. 审议关于访问域名注册数据的 SSAC 公告 (SAC101)

      鉴于安全与稳定咨询委员会 (SSAC) 于 2018 年 6 月 14 日发布了 SAC101

      鉴于 SSAC 于 2018 年 12 月 12 日发布了 SAC101 第 2 版,以“反映与 ICANN gTLD 注册数据临时规范相关的进展情况,以及正在进行的关于 gTLD 注册数据临时规范的快速政策制定流程 (EPDP)”。

      鉴于安全与稳定咨询委员会 (SSAC) 在 SAC101 第 2 版的前言中称“SAC101 第 1 版已作废,第 2 版为权威版本”。

      鉴于 ICANN 组织评估了 SSAC 在 SAC101 第 2 版中所提建议的可行性并针对各项建议编制了实施建议。

      鉴于董事会考虑了 SAC101 第 2 版中的建议和 ICANN 组织有关此建议的实施建议。

      兹此发布第 2019.06.23.04 号决议:董事会接受 SAC101 第 2 版建议事项 1,即制定并执行一项计划来实现建议中所述的四个目标,并指示 ICANN 总裁兼首席执行官或其指定人员制定计划,报告 ICANN 组织和社群在实现建议中所述四个目标方面的进展。

      第 2019.06.23.05 号决议:董事会接受 SAC101 第 2 版建议事项 2B,即澄清对在现有政策和协议下采取速率限制措施的预期目的,并指示 ICANN 总裁兼首席执行官或其指定人员与社群合作,澄清与速率限制相关的现有合同义务。

      第 2019.06.23.06 号决议:董事会记录了 SAC101 第 2 版的建议事项 2A 及 3-7,并将其转交 GNSO 理事会考虑是否应纳入 EPDP 第 2 阶段的工作。

      第 2019.06.23.04 – 2019.06.23.06 号决议的理由

      董事会今天采取此行动,是在履行考虑 ICANN 咨询委员会所提建议的承诺。此时考虑 SAC101 第 2 版是合适的,因为其中提出的许多建议事项都适合在 GNSO 正在进行的 EPDP 第 2 阶段中考虑。

      下面介绍了指导董事会作出决策的一些具体考虑因素。

      建议事项 1 建议 ICANN 董事会监督一项计划的制定和执行,以完成以下四项任务:

      1. 域名注册数据政策,包括达到收集和发布注册数据的目的。
      2. 从 WHOIS 到 RDAP 过渡。
      3. 根据详尽 WHOIS 共识性政策,将剩余的简略注册过渡到详尽。
      4. 创建经认证的 RDDS 访问项目,由 ICANN 确保创建、支持和监督技术访问机制。

      建议还认为,该计划的制定和执行应作为董事会、组织和社群的优先事项。

      董事会接受建议事项 1,因为制定计划来跟踪和报告社群和 ICANN 组织在跟进建议中所列目标方面的进展将有利于社群开展工作。董事会在接受建议事项 1 时指出:

      1. 在详尽 WHOIS 政策方面,董事会于 2019 年 3 月 14 日通过了一项决议,决定推迟合同合规工作的执行。由于此行动,ICANN 合同合规部将推迟执行以下里程碑事件,截止日期如下:
        1. 2019 年 11 月 30 日之前:注册管理运行机构必须开始接受注册服务机构针对 .COM、.NET 和 .JOBS 中的现有注册提交的详尽 WHOIS 数据。
        2. 2020 年 5 月 31 日之前:对于 .COM、.NET 和 .JOBS 中的所有新注册,各注册服务机构必须向注册管理运行机构发送详尽 WHOIS 数据。
        3. 2020 年 11 月 30 日之前:所有注册服务机构都必须完成 .COM、.NET 和 .JOBS 中所有注册向详尽 WHOIS 数据的过渡。

      此外,在 2019 年 5 月 15 日采纳有关 gTLD 注册数据新共识性政策的 GNSO 理事会政策建议时(见第 2019.05.15.09 号决议),董事会指示 ICANN 组织与实施审核小组合作,调查并透明地报告这些建议要求在多大程度上修改现有的共识性政策。董事会表示:“如果需要修改现有共识性政策,我们将呼吁 GNSO 理事会立即发起 PDP,以审核并建议对共识性政策进行的必要修改。”

      在接受建议事项 1 时,董事会进一步指出,EPDP 第 2 阶段正在讨论创建“经认证的 RDDS 访问项目”这一主题。董事会无法决定 PDP 的结果。EPDP 提交其第 2 阶段最终报告后,董事会将考虑这些政策建议。

      建议事项 2B 建议董事会指示 ICANN 组织与社群合作,“澄清对在现有政策和协议下采取速率限制措施的预期目的”。在接受建议事项 2B 时,董事会指出,社群应参与关于澄清速率限制相关现有合同义务的讨论。

      建议事项 2A 建议董事会指示 ICANN 组织与社群合作,“针对 RDDS 速率限制和相应的服务水平协议要求制定具有明确而统一目的的政策”。由于此政策由社群制定,且该主题是 EPDP 第 2 阶段工作计划的内容之一,董事会记录了这一建议并将其转交给了 PDP 管理者 GNSO 理事会。在采取此行动时,董事会还指出,在 gTLD 注册数据临时规范的附件中,董事会要求社群尽快讨论和处理速率限制主题。

      建议事项 3 建议“董事会和 EPDP 政策制定者应确保安全领域从业者和执法机构能够在适用法律允许的最大权限范围内,通过 RDDS 访问域名联系人资料”。由于这属于政策问题,且该主题是 EPDP 第 2 阶段工作计划的内容之一,董事会记录了这一建议并将其转交给了 PDP 管理者 GNSO 理事会。

      建议事项 4 建议“启动 RDS 访问收费,或者未来对 RDS 访问费用进行任何重大调整时,都必须对用户影响及安全和稳定性影响进行正式评估,且该评估应作为正式政策制定流程 (PDP) 的一部分执行”。由于这属于政策问题,且该主题是 EPDP 第 2 阶段工作计划的内容之一,董事会记录了这一建议并将其转交给了 PDP 管理者 GNSO 理事会。

      建议事项 5 重申了 SAC061 中的建议 2,并建议“ICANN 董事会确保对注册数据政策进行正式的安全风险评估,以便为政策制定流程提供意见。此外,还应针对政策的实施进行单独的安全风险评估。”该建议进一步指出“这些评估应纳入 GNSO 的 PDP 计划中。”由于该建议事项建议将这些评估纳入 PDP 计划,而 GNSO 是 PDP 的管理者,董事会记录了这一建议并将其转交给了 GNSO 理事会。

      建议事项 6 建议“ICANN 董事会指示 ICANN 组织采取行动,确保所有 RDDS 数据访问方法针对同一查询提供对等的响应”。由于这属于政策问题,且该主题是 EPDP 第 2 阶段工作计划的内容之一,董事会记录了这一建议并将其转交给了 PDP 管理者 GNSO 理事会。

      建议事项 7 建议“ICANN 董事会指示 ICANN 组织采取行动,确保通过可衡量、可强制执行且所有各方都能理解的框架提供 RDDS 访问”。由于这属于政策问题,且该主题是 EPDP 第 2 阶段工作计划的内容之一,董事会记录了这一建议并将其转交给了 PDP 管理者 GNSO 理事会。

      在考虑这些建议事项时,董事会审查了下列材料:

      董事会接受这些建议事项符合公共利益,并有助于推进 ICANN 使命的履行,因为它提高了 DNS 的安全性和稳定性。这些建议事项可以在 ICANN 组织的现有运营规划和预算中实施。

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

    4. 访问和身份管理软件的合同续约和费用支付

      鉴于 ICANN 使用 Okta 作为内外部身份管理、访问管理和单点登录解决方案。

      鉴于与 Okta Identity Management (Okta Inc.) 的当前合同条款不符合之前对 Okta 解决方案的当前和实际使用的预期。

      鉴于 ICANN 组织和董事会财务委员会已建议董事会授权 ICANN 总裁兼首席执行官或其指定人员采取一切必要行动,就 Okta 解决方案与 Okta Inc. 签订为期五年的合同,内容包括取代当前合同本年度余下期限,并根据该合同支付所有要求的费用,五年期内总金额不超过 [协商一致后确定的金额]

      兹此发布第 2019.06.23.07 号决议:董事会授权总裁兼首席执行官或其指定人员采取一切必要行动,就 Okta 解决方案与 Okta Inc. 签订为期五年的合同,内容包括取代当前合同本年度余下期限,并根据该合同支付所有要求的费用,五年期内总金额不超过 [协商一致后确定的金额]

      第 2019.06.23.08 号决议:出于谈判目的,该决议中的具体条款应按照《ICANN 章程》第 3 条第 3.5(b) 款的规定进行保密,保密期截至总裁兼首席执行官认为可以发布保密信息为止。

      第 2019.06.23.07 – 2019.06.23.08 号决议的理由

      ICANN 组织使用身份和访问管理公司 Okta Identity Management (Okta Inc.) 提供的内外部用户身份识别、访问管理和单点登录解决方案。该解决方案的名称与公司名相同,即 Okta。

      ICANN 于 2016 年 1 月与 Okta Inc. 签订了为期三年的合同,其内容包括用户登录数量和年度增长估算。初步估算以路线图和一系列假设为依据,包括某种特定使用模式和影响用户连接请求的某些增长因素。随后修订了项目路线图。与 2016 年合同中所示的 2015 年预测值相比,实际用户连接请求更低,且使用模式也有所不同。

      在重新评估当前合同时,ICANN 工程和 IT 团队与 ICANN 采购团队一起审核了保留或替换 Okta 解决方案的各种选择。审核结论是,继续使用 Okta 是 ICANN 的最佳选择,特别是 Okta 是该领域公认的全球领先企业。之后,ICANN 组织一直在与 Okta Inc. 谈判,以确保未来 Okta 解决方案的授权尽可能反映实际使用情况。

      经充分协商后,ICANN 组织收到了 Okta 的提案。提案内容包括 ICANN 组织根据当前合同已履行的期限按比例支付费用,并以比之前低许多的费用签订为期五年的新合同。

      具体而言,新拟议合同的报价要求 ICANN 组织就当前合同支付 [协商一致后确定的金额],并为新合同的第一年(直到 2020 年 6 月底)支付 [协商一致后确定的金额]。同样,剩余 4 年的合同期(到 2024 年止)每年需支付 [协商一致后确定的金额]。与当前合同相比,按照新提议的报价,ICANN 组织可在当前财年节省 [协商一致后确定的金额],并在未来五年节省大量资金。

      为确保获得合理的报价,ICANN 对比了其他具有类似用途的工具的情况。Okta Inc. 的报价与其他类似产品持平。此外,ICANN 组织解释说,更换工具还另需一次性花费约 15 万美元的更换成本,而且还需要占用大量资源和工作量。这种更换还会对正在进行的项目安排带来不利影响,这对 ICANN 没有任何明显的好处。

      经过对这些方案的评估之后,ICANN 组织和董事会财务委员会 (BFC) 建议继续与 Okta Inc. 签订合同,为 ICANN 当前和未来五年内的预计需求提供最佳支持。董事会同意此建议。

      此行动显然符合 ICANN 的使命,因为正在讨论的这一解决方案可帮助内外部利益相关方访问 ICANN 的系统和信息,而且在可行的情况下节省成本符合公共利益。

      此决定将产生财务影响,2020 财年预算中已考虑此授权所需的资金。2021 至 2024 财年预算中也将考虑此项资金。

      此行动应不会对域名系统产生负面影响。

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

    5. 感谢第 65 届 ICANN 会议的当地主办机构

      董事会感谢摩洛哥外交与国际合作部、工业、贸易和投资部、数字经济部及我们的主办机构、ANRT 局长阿兹·厄尔·阿拉贝·哈斯比 (Az-El-Arabbe Hassibi) 先生及其团队的大力支持。

    6. 感谢第 65 届 ICANN 会议的赞助商

      董事会希望对以下赞助商表示感谢:Neustar。

    7. 感谢第 65 届 ICANN 会议的口译员、工作人员以及会议和酒店团队

      董事会对速记员、口译员、视听团队、技术团队和全体 ICANN 组织工作人员为会议顺利进行所付出的努力表示最深的谢意。董事会还要感谢马拉喀什棕榈园会议中心 (Palmeraie Conference Center Marrakech) 的管理层和工作人员为召开本次会议提供了优良的场所和设施。特别感谢棕榈园会议中心团队的哈姆扎·博扎 (Hamza Bouza)、罗姆纳·厄尔·麦加维 (Loubna El Mekkaoui)、莫娜·厄尔·奥芙 (Mona El Ourf)、萨利马·拉里菲 (Salima Lakhlifi)、内扎·阿拉拉维 (Nezha Alaalaoui)、穆罕默德·马蒂里 (Mohammed Matiri)、哈姆扎·厄尔·艾迪 (Hamza El Aidi)、马里亚姆·西泰德 (Meriem Setad) 及 ASP 团体经理巴特·万·坎彭 (Bart Van Campen)。

  2. 主要议程:

    1. 批准 ICANN《2021-2025 财年战略规划》

      鉴于根据《ICANN 章程》第 22.5(b) 款的规定,ICANN 有义务编制 2021-2025 财年的五年战略规划,这是 IANA 管理权移交后的第一个战略规划。

      鉴于在 2017 年 11 月至 2018 年 6 月期间收到社群、董事会和 ICANN 组织对未来几年间影响 ICANN 的主要趋势的意见后,董事会进行了分析并发现,各种有关趋势的讨论会议中囊括了一些极其相似的话题,主要可归入五大关键领域:安全性、治理、唯一标识符系统、地缘政治和财务状况。

      鉴于社群在 ICANN63 巴塞罗那会议召开前和召开期间对这些趋势进行了探讨。ICANN63 会后,我们通过与社群展开对话,获取了一些其他意见,董事会现已编制了一份 ICANN 的《2021-2025 财年战略规划》,从而呈交给社群进行协商。这份文件囊括了 ICANN 的使命、ICANN 的未来发展愿景、一套战略宗旨和目标,以及期望实现的成果和相关风险。

      鉴于已依照《章程》于 2018 年 12 月 20 日发布了《2021-2025 财年战略规划》草案以征询公众意见。

      鉴于 ICANN 董事会和 ICANN 组织成员在 ICANN63 和 ICANN64 期间与社群成员召开了两次公开会议,共同确定了 ICANN 2021-2025 财年的优先事项和战略方向,并确保充分理解和适当考虑收到的意见。

      鉴于已对收到的公众意见进行了考虑,以确定需要对《2021-2025 财年战略规划》草案进行哪些修改。

      鉴于除了公众意见征询流程之外,ICANN 组织还通过其他方式积极征求了社群的反馈并与 ICANN 社群进行了协商,包括在 ICANN61 和 ICANN62 期间与多利益相关方团体召开战略前景趋势识别会议、召开网络研讨会、发布博文、在战略规划网页上定期更新下一个五年战略规划的编制进展等。

      鉴于董事会在 ICANN 组织的支持下成立了一个核心小组,负责领导 ICANN 下一个战略规划的编制。董事会战略规划核心小组在审核与分析趋势工作的结果及其相关机遇、风险和对 ICANN 的影响,将这些信息纳入新战略宗旨与目标,以及编制规划供全体董事会考量方面发挥核心作用。

      鉴于董事会在近期举行的各场工作坊上讨论了《2021-2025 财年战略规划》的编制问题,并就此为核心小组和 ICANN 组织提供了指导。

      兹此发布第 2019.06.23.09 号决议:董事会通过 ICANN《2021-2025 财年战略规划》。

      第 2019.06.23.10 号决议:这份《战略规划》的负担能力将作为目前正在编制的《五年运营和财务规划》中所需考量的一部分。如果出现任何影响此《战略规划》实施的可行性的问题,届时董事会将作出进一步指示。

      第 2019.06.23.11 号决议:董事会指出,作为正在与社群协商的年度规划制定周期的一部分,ICANN 规划的年度编制必须考虑新趋势或现有趋势的变化。如果这些审核的结果表明需要大幅修改 2021-2025 财年战略规划中的任何战略宗旨,董事会届时将作出适当流程和行动的指示。

      第 2019.06.23.09 – 2019.06.23.11 号决议的理由

      根据《ICANN 章程》第 22.5 (b) 款的规定,董事会需在每个五年财年期开始之前通过五年战略规划并将其发布在 ICANN 网站上,此规定下的第一个五年期为 2021 至 2025 财年。ICANN《2021-2025 财年战略规划》草案于 2018 年 12 月 20 日发布以征询公众意见。

      提交董事会批准的战略规划采用分阶段方法制定,具体包括四个步骤:趋势识别、趋势分析、起草战略规划和战略规划定稿。

      战略规划制定流程旨在确保 ICANN 社群参与规划制定的整个过程。这包括与利益相关方团体召开战略前景趋势识别会议、通过网络研讨会分享相关信息、在 ICANN 大会期间举行公开会议以及通过公共评议的机会提供关于战略规划编制的建议。

      2017 年 11 月至 2018 年 6 月期间,ICANN 组织在组织内部举行了 14 次部门和区域运营中心趋势识别工作坊,并与社群和董事会召开了 11 次会议,共收集到 1,000 余份趋势数据建议。

      2018 年 4 月至 2018 年 9 月期间,董事会及其负责监督战略规划制定流程的核心小组在 ICANN 组织的支持下,审核并分析了趋势工作的结果及其相关机遇、风险和对 ICANN 的影响。

      2018 年 9 月至 2019 年 3 月期间,除了征询公众意见之外,ICANN 还在多个场合积极征求了社群的反馈并与 ICANN 支持组织、咨询委员会及其他利益相关方团体进行了磋商:

      • 2018 年 10 月 9 日召开网络研讨会,概述了战略规划的流程,并介绍了 ICANN 组织及其董事会从战略前景趋势会议中得出的结论和后续分析结果。
      • 在 ICANN 第 63 届巴塞罗那会议期间举行的一场高关注度公共会议上,董事会和 ICANN 组织成员与社群讨论了制定 ICANN 下一个 5 年战略规划时所需应对的战略问题和工作要务。
      • 在 ICANN 第 64 届神户会议上,ICANN 社群、组织和董事会举行了另一场关于战略规划的公开会议,以确保充分理解和适当考虑收到的意见,此次会议也受到了高度关注。

      2019 年 3 月至 5 月期间,对通过各种方式收到的所有意见进行了考虑,以最终确定 ICANN《2021-2025 财年战略规划》。在可行和适当的情况下,这些意见已被纳入提请批准的 ICANN《2021-2025 财年战略规划》。有关在规划草案修订中对各项意见的考虑情况,可访问 ICANN.org 查看。

      根据组织《章程》,ICANN《2021-2025 财年战略规划》是 ICANN 治理工作的一项基础任务。ICANN 五年战略规划是 ICANN 三重规划流程周期中的一个核心元素,另外两重为:五年运营和财务规划和年度运营规划和预算。战略规划为我们所期待的未来发展确定了方向(“愿景”),并列出必须实现的重要成果和具体成就,从而成功地履行 ICANN 的使命,实现组织愿景。

      战略规划的实施需要 ICANN 董事会、组织和社群提供大量资源并作出承诺。未来五年,ICANN 生态系统中的每个部分都将在自身的 ICANN 工作中推进战略规划的实施,在这方面发挥重要作用。在征询大量社群意见的基础上确定的共同愿景需要所有人齐心协力才能实现。

      此决定将对 ICANN 和所针对的社群产生财务影响。就针对域名系统 (DNS) 的安全、稳定与弹性方面的资金而言,该决定应该会对 DNS 的这些方面产生积极影响。

      此项决议有助于 ICANN 履行其确保互联网唯一标识符系统安全稳定运行的使命。ICANN《2021-2025 财年战略规划》立足于 ICANN 的使命,让其可以继续有效地实现目标,应对不断变化的新挑战和新机遇。

      该决议符合公共利益,因为《战略规划》将指导 ICANN 的活动,为 ICANN 的运营规划和预算提供参考,以便其在 2021-2025 财年履行好自己的使命。《战略规划》为实现支持单一、开放、全球互用的互联网这一新愿景指明了道路,因此有利于公共利益。《战略规划》符合 ICANN 的承诺,并以 ICANN 核心价值观为指导。

      这属于组织管理职能,已征询公众意见(如上所述)。

    2. 转让 .BJ(贝宁)顶级域

      兹此发布第 2019.06.23.12 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,IANA 审核并评估了将 .BJ 国家和地区顶级域转让给 Autorité de Régulation des Communications Electroniques et de la Poste du Bénin (ARCEP BENIN) 的请求。相关文件证明,在评估该申请时遵循了适当的程序。

      第 2019.06.23.12 号决议的理由

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

      根据《IANA 域名职能合同》的要求,IANA 已评估一项 ccTLD 转让申请,且目前正向董事会提交报告供其审核。提请董事会审核的目的是确保严格遵守相应流程。

      正在考虑的提案是什么?

      提案计划批准国家和地区顶级域 .BJ 的转让申请,并向 Autorité de Régulation des Communications Electroniques et de la Poste du Bénin (ARCEP BENIN) 授予管理机构角色。

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

      在评估此转让申请的过程中,PTI 咨询了申请人和其他重要利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其在本地互联网社群中的适用性。

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

      PTI 未收到社群就此申请提出的重大问题或疑虑。

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

      董事会审核了以下评估:

      [已删除 — 敏感授权信息]

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

      董事会未发现此申请存在任何特定隐患。

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

      及时批准符合各种公众利益标准的国家和地区域名管理机构对 ICANN 的整体工作会有积极影响,对此类国家和地区顶级域所服务的当地社群也会有积极作用,同时还可体现积极履行 IANA 域名职能合同中所述的职责。

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

      管理 DNS 根区中的国家和地区代码授权是 IANA 的职责,授权行动不会对预先计划的开支有任何重大影响。评估国家和地区顶级域在特定国家和地区内部运营所产生的财务影响并不是 ICANN 的职责。

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

      ICANN 认为此申请不会对安全、稳定或弹性造成明显不利影响。

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

    3. 根据《ICANN 章程》第 4 条第 4.6 款的规定批准用于指导执行特定审核的《运营标准》

      鉴于 ICANN 组织根据《ICANN 章程》第 4 条第 4.6 款的规定,与 ICANN 社群协商编制了《运营标准》,为执行特定审核提供指导。

      鉴于 ICANN 组织于 2017 年 10 月发布了《运营标准》初稿征询公众意见,并于 2018 年 12 月发布了更新版草案征询公众意见。ICANN 社群通过两次公众意见征询及 ICANN57ICANN58ICANN60ICANN63ICANN64 上的公共会议,以及 2017 年 2 月2017 年 10 月2018 年 10 月举行的网络研讨会对《运营标准》的编制提供了意见。

      鉴于 ICANN 组织纳入了 ICANN 社群在关于《运营标准》的公共评议期、公开会议和网络研讨会上提供的反馈意见,以及社群在特定审核时间长期调整方案公共评议期提供的意见。此外,ICANN 组织还纳入了最近进行和正在进行的特定审核中的最佳实践。

      鉴于《运营标准》解决《章程》中所述的必要事项(见第 4.6 (a) (i) 款),具体涉及:候选人提名、审核小组选择、审核小组规模、利益冲突政策、决策程序、独立专家招募及审核小组在保密披露框架下对保密文档的访问权限。

      鉴于董事会组织效率委员会在《运营标准》的整个编制过程中收到了 ICANN 组织的实质性和程序性简报。

      兹此发布第 2019.06.23.13 号决议:董事会批准根据《章程》第 4.6 款为执行审核而制定的《特定审核运营标准》。

      第 2019.06.23.14 号决议:董事会确认《运营标准》符合《章程》要求,指示 ICANN 组织在 ICANN 网站上公布此《运营标准》。《运营标准》应根据其第 6 部分的要求视需要予以更新,以确保此文件始终满足 ICANN 社群、ICANN 董事会和 ICANN 组织的要求,为有效和高效执行当前和未来的特定审核提供支持。

      第 2019.06.23.13 – 2019.06.23.14 号决议的理由

      正在考虑的提案是什么?

      正在考虑的提案是由董事会根据《章程》第 4.6 款的规定批准《特定审核运营标准》。

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

      特定审核以《ICANN 章程》第 4 条第 4.6 款为依据,是 ICANN 问责制措施中不可或缺的一部分。《章程》中规定了四种特定审核:问责制和透明度审核;安全、稳定与弹性审核;竞争、消费者信任和消费者选择审核;以及注册目录服务审核。

      《章程》第 4.6 款要求制定《运营标准》,为这些由 ICANN 社群执行、ICANN 组织推动、ICANN 董事会监督的审核工作提供支持。具体而言,第 4.6 款要求《运营标准》符合与以下事项相关的指导标准:候选人提名、审核小组选择、审核小组规模、利益冲突政策、决策程序、独立专家招募及审核小组在保密披露框架下对保密文档的访问权限。《运营标准》需解决以上所有问题并符合《章程》要求。遵循此《运营标准》将使特定审核以透明、一致、高效和可预测的方式执行,并支持社群的工作,从审核流程中获得预期的效益和价值。

      ICANN 社群的意见

      ICANN 组织通过两次公众意见征询、三场网络研讨会和 ICANN 大会期间举行的五次公开会议与 ICANN 社群进行了密切磋商,共同促成了此《运营标准》的制定:

      首先,ICANN 组织在 ICANN57 期间组织了一次公开会议,让社群就《运营标准》的制定分享意见,目的是使特定审核更加高效、一致和透明。

      2017 年 2 月,ICANN 组织举办了一场网络研讨会,以获得社群在制定《运营标准》的流程方面的支持,以及对该文件将涵盖的一些主要问题的反馈意见,例如审核小组选择流程。

      2017 年 3 月 ICANN58 期间举行了另一场公共会议,以向社群分享最新进展并获取关于起草该文件的其他实质性和流程性建议。

      2017 年 10 月,ICANN 组织发布了《运营标准》的第一版完整草案,用以征询公众意见。该文件发布后再次举行了一场网络研讨会,会上对该文件进行了简要介绍,让社群提供了反馈意见并设置了一个超长的问答环节。此外,ICANN 组织还于 2017 年 10 月 ICANN60 期间的公开会议上展示了该草案。为期 90 天的公共评议期共收到了 10 份意见,其中一些来自 GAC、GNSO 理事会和 ccNSO 理事会。评论者提供了建设性的反馈意见,支持了一些提案并对其他提案持保留意见,包括提议的范围设置程序和由 SO/AC 主席选择审核小组成员的遴选流程。

      ICANN 组织于 2018 年 10 月 ICANN63 期间召开了会议,重点讨论了《运营标准》的一些内容:范围设置、审核小组选择及 ICANN 特定审核决策程序。在准备《运营标准》的下一个草案版本时,ICANN 组织另外举行了一场网络研讨会,重点讨论了《运营标准》草案几点关键内容的拟议更新,并提供了这些内容的拟议批准时间表。

      2018 年 12 月,ICANN 组织发布了《运营标准》的更新版草案,用以征询公众意见。为期 65 天的公共评议期共收到了六份意见,其中提供了建设性的反馈,大多数意见持支持态度。这六份意见包括建议对《运营标准》草案的 48 处进行修改,其中 ICANN 组织能够处理的为 43 处;其余五份意见未予以采纳,因为它们要么是未得到广大社群支持的个人建议,要么就不符合《章程》或现有的最佳做法,不具备可行性。最后,ICANN 组织还在 2019 年 3 月 ICANN64 期间举行了最后一次公开会议,会上概述了收到的公众意见以及如何将这些意见纳入文件终稿。

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

      在两次公众意见征询、三场网络研讨会和 ICANN 大会期间举行的五次会议中,ICANN 社群对《运营标准》草案中包含的具体提案提出了一些疑虑。

      例如,该文件的初稿提出了一个审核小组范围设置程序,公众意见征询期间有许多评论者表示反对。同样,在第二次公众意见征询期间,有人提出应更详细地描述审核小组及审核小组领导层的角色和职责,并更清晰地阐明解决审核小组成员之间冲突的具体流程。所有这些意见都导致了草案变更,简化了审核小组的范围设置流程,且更详细地描述了角色和职责以及冲突解决程序。因此,文件终稿反映了社群的意见。

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

      ICANN 董事会审核了所有与制定《运营标准》相关的文件,包括草案文件和公众意见总结。董事会成员也出席了 ICANN 大会期间举行的会议和网络研讨会。

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

      这项董事会行动预计会对社群产生积极影响,因为《运营标准》将为特定审核小组的工作提供支持,促进特定审核以透明、一致、高效和可预测的方式执行。

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

      这项董事会行动预计不会对 ICANN 的财务产生不良影响。遵循《运营标准》预计将有利于简化社群主导的审核小组的工作,并使该小组的工作得到 ICANN 组织的支持和帮助。

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

      此项董事会行动预计不会对与 DNS 有关的安全、稳定或弹性问题造成直接影响。

      这项行动是否符合 ICANN 的使命以及它所服务的公共利益是什么?

      董事会的行动符合 ICANN 根据《章程》第 4 款做出的确保 ICANN 的多利益相关方模型保持透明、负责的承诺,且符合第 4.6 款所述通过社群协商制定《运营标准》的要求。

      董事会采取行动前是否需要征询公众意见?

      《运营标准》草案共有两个版本进行公众意见征询(2017 年 10 月2018 年 12 月);在董事会采取行动前,无需进行额外的公众意见征询。

    4. 通过安全与稳定咨询委员会第二次组织审核的最终报告、可行性评估与实施规划

      鉴于 SSAC 的第二次组织审核已根据《ICANN 章程》第 4 条第 4.4 款于 2018 年 2 月启动。

      鉴于进行第二次 SSAC 审核的独立审核人编制了评估报告,该报告于 2018 年 6 月 21 日发布以进行公共协商,2018 年 10 月 15 日发布了最终报告草案征询公众意见,并于 2018 年 12 月 17 日提交了包含三十 (30) 项建议的最终报告

      鉴于 ICANN 社群通过公众意见征询流程对最终报告草案提供了意见。

      鉴于 SSAC 审核工作组 (SSAC RWP) 作为 SSAC、独立审核人和 ICANN 董事会组织效率委员会 (OEC) 之间的联络人,在其可行性评估与实施规划(可行性评估)中分析了独立审核人建议的可行性和有效性,考虑了临时预算影响,并预测了提出优先化的实施时间表所需的资源。

      鉴于 SSAC RWP 在其可行性评估中支持十九 (19) 个问题及其相应建议;SSAC RWP 支持六 (6) 个问题但不支持其相应建议,而是提供了替代性建议;SSAC RWP 支持一 (1) 个问题但不支持其相应建议,且未提供替代性建议并提供了详细解释;SSAC RWP 不支持四 (4) 个问题,因此也不支持其相应的建议。

      鉴于 SSAC 于 2019 年 5 月 13 日批准了该可行性评估。

      鉴于 OEC 在 2019 年 5 月 23 日的 OEC 会议期间收到了来自独立审核人有关其最终报告的简报以及来自 SSAC 审核工作组有关其可行性评估的简报。

      鉴于 OEC 审议了最终报告、可行性评估和公众意见,以便就如何进行第二次 SSAC 审核向董事会提出建议。OEC 建议董事会接受 SSAC 审核独立审核人的最终报告以及 SSAC 审核工作组的可行性评估。OEC 也建议董事会指示 SSAC 组建一个实施工作组,以便在通过该决议后六 (6) 个月内,针对可行性评估中详述的建议制定一个详细的实施规划。详细的实施规划也应包括适当的实施成本规划。OEC 还建议董事会,在董事会批准上述详细的实施规划(包括适当的实施成本规划)后,实施工作组应监督这些建议的实施情况。

      兹此发布第 2019.06.23.15 号决议:董事会接受独立审核人的最终报告。

      第 2019.06.23.16 号决议:董事会接受可行性评估。

      第 2019.06.23.17 号决议:董事会指示 SSAC 组建一个 SSAC 审核实施工作组,负责针对可行性评估中所述的建议起草一个详细的实施规划,包括适当的实施成本规划。

      第 2019.06.23.18 号决议:详细的实施规划应尽快提交给董事会,但不得晚于通过本决议后六 (6) 个月。该详细实施规划应包括实际可行的实施时间表、预期成果的定义、如何通过实施来解决最终报告中确定的基本问题的说明、当前状态的衡量方式和实现预期成果的实施进度。工作组也应与 ICANN 组织合作,将各个实施步骤的预期预算影响纳入其详细的实施规划中。该实施规划应纳入分阶段方法,允许首先实现易于实施且成本最低的改进,对于那些具有更明显预算影响的项目,将在实施流程中的晚些时候解决。

      第 2019.06.23.19 号决议:董事会指示 SSAC 审核实施工作组在董事会接受详细的实施规划后监督实施流程。因实施而提出的任何预算申请应根据 ICANN 组织的年度预算编制流程提出。

      第 2019.06.23.20 号决议:董事会指示 SSAC 审核实施工作组每六 (6) 个月向 OEC 提供一次有关实施规划进度的实施报告,包括但不限于实施规划中详述的衡量标准的完成进度以及所分配预算的使用情况。

      第 2019.06.23.15 – 2019.06.23.20 号决议的理由

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

      为确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其绩效,ICANN 依照其《章程》第 4 条第 4.4 款所述,对其支持组织、咨询委员会(除政府咨询委员会外)和提名委员会进行了组织审核。第二次 SSAC 审核于 2018 年 2 月启动。执行审核的独立审核人编制了最终报告,该报告已于 2018 年 12 月公布。SSAC 审核工作组根据其对独立审核人的最终报告进行的详细审核编制了可行性评估,并于 2019 年 5 月 13 日获得 SSAC 批准

      独立审核

      2018 年 2 月,根据 ICANN 的聘用流程,Analysis Group Consulting Group, LLC 被任命为 SSAC 审核的独立审核人。ICANN 的聘用流程使得 ICANN 组织人员和董事会组织效率委员会 (OEC) 得以参与进来,后者负责监督组织审核流程。在其工作期间,Analysis Group 审核了相关文档,与 SSAC、广大 ICANN 社群、ICANN 董事会和 ICANN 组织的成员进行了 42 次访谈,其在线调查收集了 52 项单独回复。此外,审核期间 Analysis Group 与 SSAC 审核工作组召开了例行会议,包括在 ICANN611ICANN 62ICANN63 期间召开的公共会议。

      SSAC 审核工作组向 Analysis Group 提供了有关评估报告初始草案和最终报告草案初始草案的直接反馈。Analysis Group 考虑了该反馈,并根据其独立角色和专业判断纳入了其认为适当的要素。

      根据标准的 ICANN 流程,最终报告草案2018 年 10 月 15 日公布以征询公众意见。Analysis Group 针对 2018 年 11 月 22 日的最终报告草案举行了社群网络研讨会

      Analysis Group 于 2018 年 12 月 17 日提交了最终报告。最终报告叙述了独立审核人发现的基本问题以及独立审核人作为解决这些问题的提案提出的三十 (30) 项建议。

      SSAC 审核工作组

      在其可行性评估中,SSAC RWP 详细解释了其各项担忧以及同意最终报告中三十 (30) 个议题的理由。SSAC RWP 分析了独立审核人关于可行性和实用性的建议,考虑了临时预算影响,并预计了拟定优先实施时间表所需的资源。评估结果如下:SSAC RWP 支持十九 (19) 个问题及其相应建议;SSAC RWP 支持六 (6) 个问题但不支持其相应建议,而是提供了替代性建议;SSAC RWP 支持一 (1) 个问题但不支持其相应建议,且未提供替代性建议并提供了详细解释;SSAC RWP 不支持四 (4) 个问题,因此也不支持其相应的建议。

      SSAC RWP 不支持的四个问题中,有三个(#17、#22 和 #23)与开展更多外展和/或加强广大 ICANN 社群内部沟通的需要有关。SSAC RWP 不支持这些问题的原因在于,SSAC 的职权范围有限且其成员规模较小,而这对其有效运作至关重要,因此无法扩展其当前的外展范围。不支持的第四个问题 (#13) 与要求设置 SSAC 分析的安全数据存储位置有关,SSAC RWP 解释称 SSAC 目前无此必要。

      SSAC RWP 在提供替代性建议时调整了独立审核人的建议,使其更加适合 SSAC 的需求。例如,与建议为研究生创建实习岗位来协助研究项目(建议 #12)不同,SSAC RWP 提议创建实习岗位来吸引更多经验丰富的人才,并更多地依赖 ICANN 技术人员。对于其他情况,SSAC RWP 拒绝了独立审核人关于制定更详细的招聘计划的建议(建议 #21、#24 和 #25),因为这一观点让 SSAC RWP 感到“不安”。反之,SSAC RWP 建议“SSAC 制定一个正式的流程来估算预期未来工作所需的非技术专业知识,从而确定当前成员所面临的技能差距”。此外还建议“成员资格委员会在评估新成员申请时考虑非技术专业知识差距”。

      总体而言,SSAC RWP 解释了其担忧以及不支持独立审核人建议的理由,并提供了所提议的替代性建议的背景信息。

      ICANN 社群的意见

      除了 Analysis Group 通过访谈和在线调查以及有关评估报告的公共协商收集的回复外,在针对最终报告草案征询公众意见期间,总共提交了六 (6) 项意见;其中两 (2) 项由个人贡献者提交,四 (4) 项由组织提交(参见公共评议期摘要报告)。除了有一位评论者认为审核超出了范围之外,在公共评议期献言的其他 ICANN 社群成员均支持最终报告草案。其他所有献言者都非常支持有关 SSAC 长期目标的建议。例如,注册管理机构利益相关方团体 (RySG) 指出,他们“重视 SSAC 在为 ICANN 董事会提供技术建议方面发挥关键作用时所表现出的能力和效率,并相信 ICANN 董事会做出的决策会在 SSAC 的技术建议下总体得到完善”。献言者还支持关于 SSAC 生成建议和向 ICANN 董事会提供建议的建议,一般会员咨询委员会 (ALAC) 评论称“虽然其赞赏 SSAC 以更好地与董事会沟通的方式编写建议,但 SSAC 同时也应尝试使用让 ICANN 社群更易理解的方式”。献言者强烈支持关于 SSAC 与 SO/AC 和 ICANN 社群合作的建议,例如,企业选区 (BC) 指出:“SSAC 应大力加强与其他 SO/AC 小组的互动”。此外,虽然大多数献言者表示支持关于 SSAC 的规模、成员资格和任期长度的建议,但非商业利益相关方团体 (NCSG) 仍然坚持“其应继续保持非领导层成员任期限制的立场”。最后,关于对 SSAC 先前的审核实施和持续自我改进的建议,既无人支持也无人反对。

      OEC 和董事会的考量及行动

      作为负责监督组织审核的 ICANN 董事会委员会,OEC 详细审核了与 SSAC 审核有关的所有相关文件。具体而言,OEC 分别考虑了最终报告和可行性评估、公众意见及来自独立审核人和 SSAC 审核工作组的简报和意见。OEC 建议董事会采取此项行动,以继续执行 SSAC 组织审核流程。

      采取此项行动时,董事会同意可行性评估适当地回复了审核期间独立审核人提出的问题。实施 SSAC 审核工作组提议的改进是确保审核后 SSAC 能够履行《章程》规定的角色和职责的一个重要步骤。

      为了确认 SSAC 适当地推进该流程,董事会指示 SSAC 组建一个实施工作组,向其提供详细的实施规划,包括简要概述 SSAC 审核工作组各项实施提案的当前状态、明确定义的实施目标、适当的实施成本规划、优先次序和资源影响以及如何持续测量实施进度的方法。董事会认为这些衡量标准将有助于确保实施流程的问责制和透明度,促成有意义的、具有预算意识的改进,从而进一步加强 SSAC 在就与互联网名称和地址分配系统安全性与整合性相关的问题向 ICANN 董事会提供建议方面的关键性作用。

      组织审核流程是一个重复性流程,董事会希望 ICANN 社群的所有各方将继续开展卓有成效的工作,以便了解各个 SO/AC 的独特角色以及它们带给 ICANN、其政策制定工作和跨社群工作的观点。董事会期待精简组织审核流程这一工作取得成果,并在下一轮审核之前完成,以进一步改进和完善组织审核流程。

      OEC 在审议 SSAC 的可行性评估时发现,ICANN 组织可能可通过其他方式支持 SSAC,特别是在 SSAC 与广大社群的互动方面以及就特定问题为董事会提供“快速审查”方面。后者是最终报告和可行性评估的建议 #7 中所含的内容。董事会指出,在这些情况下,ICANN 组织和总裁将分别并同时负责为各项 SSAC 审核实施工作提供充分的 ICANN 组织支持。董事会鼓励 ICANN 组织和 SSAC 如以上董事会决议所述,开始就该流程进行协商,与起草详细的实施规划同时但分开进行。

      董事会还指出,OEC 和 SSAC 讨论了将 SSAC 的战略重点与 ICANN 战略规划相结合的价值。

      正在考虑的提案是什么?

      正在考虑的提案是由董事会接受独立审核人的最终报告和 SSAC RWP 的可行性评估。董事会还指示 SSAC 组建一个实施工作组,负责起草详细的实施规划,监督 SSAC 审核工作组的可行性评估中详述的建议的实施情况,并每六 (6) 个月向 OEC 提交一次详细说明实施进度的书面报告。

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

      董事会考虑了相关的《章程》规定、独立审核人的最终报告、SSAC 审核工作组的可行性评估以及社群就独立审核人的评估报告和最终报告草案提供的反馈,并在作出此决策时将 OEC 考虑的情况纳入考虑范围。

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

      这项董事会行动预计会对社群产生积极影响,因为它支持根据《章程》的要求促进对 ICANN 的支持组织和咨询委员会进行定期审核的持续流程。此外,本着持续改进的精神,实施建议将会提高 SSAC 的透明度、问责制和效率。

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

      此项董事会行动可能会产生财务影响,这些财务影响将被编入接下来的详细实施规划中,董事会日后会考虑该实施规划。详细的实施规划应概述如何将任何预算要求纳入未来的 ICANN 预算周期中。

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

      此项董事会行动预计不会对与 DNS 有关的安全、稳定或弹性问题造成直接影响。

      这项行动是否符合 ICANN 的使命以及它所服务的公共利益是什么?

      董事会的行动符合 ICANN 根据《章程》第 4 条做出的承诺,即确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其支持组织和咨询委员会的绩效。

      这项行动将通过履行 ICANN 维护和改进其问责制和透明度的承诺来为公共利益服务。

      董事会采取行动前是否需要征询公众意见?

      独立审核人的最终报告草案已发布,用以征询公众意见。在董事会采取行动前,无需征询额外的公众意见。

    5. GNSO 注册服务机构利益相关方团体章程修正案

      鉴于 ICANN 章程(第 11 条第 11.5 c 款)规定,“第 11.3(a) 款确定的每个利益相关方团体及其每个关联的选区,在适当情况下都应始终得到 ICANN 董事会的认可。”

      鉴于董事会现已确立了 GNSO 利益相关方团体和选区章程修订流程(下文简称“流程”);

      鉴于 GNSO 注册服务机构利益相关方团体 (RrSG)、ICANN 组织和董事会组织效率委员会 (OEC) 已完成截至目前该流程中已确定的所有步骤,且 OEC 认为目前是董事会考虑这些拟议变更的合适时机。

      兹此发布第 2019.06.23.21 号决议:ICANN 董事会批准本文件中记录的注册服务机构利益相关方团体章程修正案以及附件。现指示 ICANN 总裁兼首席执行官或其指定人员向 RrSG 领导层传达本决议,并指示 RrSG 和 ICANN 总裁兼首席执行官(或其指定人员)提供对相应 ICANN 和 RrSG 网页上已更新的 RrSG 章程的访问权限。

      第 2019.06.23.21 号决议的理由

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

      《ICANN 章程》(第 11 条第 11.5 c 款)规定,“第 11.3(a) 款确定的每个利益相关方团体及其每个关联的选区,在适当情况下都应始终得到 ICANN 董事会的认可。ICANN 董事会遵循一项流程来正式批准任何 GNSO 利益相关方团体和/或选区章程修正案,以便为维持认可提供支持。

      2013 年 9 月,董事会制定了修订 GNSO 利益相关方团体和选区章程的流程(以下简称“流程”),为达到 ICANN 章程要求提供了一个简便的方法。

      2018 年 6 月,GNSO 的注册服务机构利益相关方团体 (RrSG) 批准了其治理文件修正案并充分利用这一流程

      考虑了哪些提案?

      注册服务机构利益相关方团体 (RrSG) 大幅修改了现有章程文件,以针对成员组成变化作出调整,更有效地履行其政策制定职责。在修正条款中,最大的章程变更在以下方面:

      • 对文件进行了重新编排和格式调整,包括根据 GNSO 运营规程和《ICANN 章程》提供的内容,使其与 GNSO 的其他“最佳”章程保持一致;
      • 澄清了 RrSG 成员资格的各个方面,特别是合格成员的定义、有/无表决权的地位以及与不合格申请人相关的事项;
      • 其他成员代表信息:概述成员代表、候补成员代表和成员参与者的不同身份状况;
      • 扩展了关于执行委员会角色、职责和资格以及新增设副主席职位的规定;
      • 增加了关于 GNSO 理事会代表和提名委员会代表的详细信息,特别是有关 RrSG 的资格和职责的内容;
      • 增加了与决策相关的内容,澄清了关于 RrSG、选举和政策评论/意见起草的任何决策情况的流程;
      • 新增设一个副主席职位,使副主席职位增加到两个,即技术运营副主席和政策协调副主席;
      • 增加了关于 RrSG 内其他委员会运营的章节;
      • 增加了关于沟通的章节:RrSG 网站、分发列表和信息发布政策;
      • 增加了概述以下流程的章节:成员会议、外展和财务;
      • 整体扩展治理文档,添加可供成员参考的流程并增加定义部分,以提供文件中所用术语的定义。

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

      除在 RrSG 内进行广泛的社群审议外,拟议修正案还接受了 50 天的公众意见征询(2018 年 12 月 18 日至 2019 年 2 月 5 日)。公众意见征询期结束后,ICANN 组织在 2019 年 2 月 7 日提交总结报告供社群和董事会 OEC 审核。ICANN 组织还根据章程审核流程审核了财务和责任问题的相关文档。

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

      董事会成员审核了拟议的章程修正案,在初始员工审核之后、公众意见征询之前审核了拟议章程修正案的红线版本,以及审核了汇总社群意见的员工摘要报告、公众意见问题跟踪检查清单、RrSG 执行委员会和 ICANN 组织在处理 ICANN 组织之前提出的担忧时编制的支持性文档。

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

      GNSO 注册服务机构利益相关方团体、ICANN 组织及组织效率委员会已完成该流程中已确定的所有步骤,并发布了修正案供社群审核与评议。OEC 已向董事会建议称,目前是董事会考虑是否批准 RrSG 章程修正案的合适时机,虽然 ICANN 组织对更新后的章程提出了疑虑。提出此建议的原因是,在公众意见征询流程中,虽然 ICANN 组织已公布其疑虑,但社群未对此提出意见或表示担忧,而且 ICANN 社群未曾收到任何不赞成拟议修正案的评论。

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

      RrSG 已修改了现有章程文件,以针对成员组成变化作出调整,更有效地履行其政策制定职责。在为期 50 天的公众意见征询程序中,ICANN 社群成员未对新 RrSG 章程草案中所述的规定提出任何疑虑。

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

      提供的修正案预计不会对 ICANN 或个人社群成员产生财务影响/后果。提供的修正案更新了 ICANN 董事会认可的选区团体之一的基本治理文件,符合 ICANN 的使命和公共利益。

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

      此决定预计不会对域名系统的安全性、稳定性与弹性造成任何影响。

      这是属于 ICANN 支持组织内部定义的政策流程,还是属于需要(或不需要)征询公众意见的 ICANN 组织管理职能决策?

      拟议的 RrSG 章程修正案接受了 50 天的公众意见征询(2018 年 12 月 18 日至 2019 年 2 月 5 日)。在董事会采取行动前,无需征询额外的公众意见。

    6. 其他事务

      未达成任何决议。

  3. 执行会议:

    1. 总裁兼首席执行官 2019 财年下半年风险薪酬和 2020 财年目标

      鉴于各董事会成员已确认其在确定总裁兼首席执行官 2019 财年下半年的风险薪酬部分方面没有利益冲突。

      鉴于薪酬委员会建议董事会批准向总裁兼首席执行官支付其 2019 财年下半年的风险薪酬部分。

      鉴于薪酬委员会已与总裁兼首席执行官共同为后者制定了 2020 财年的一系列风险薪酬部分目标。

      兹此发布第 2019.06.23.22 号决议:董事会特此批准向总裁兼首席执行官支付其 2019 财年下半年的风险薪酬部分。

      第 2019.06.23.23 号决议:董事会特此批准总裁兼首席执行官的 2020 财年风险薪酬部分目标。

      第 2019.06.23.24 号决议:根据《ICANN 章程》第 3 条第 3.5(b) 和 3.5(d) 款,本决议中的特定项目仍将作为“与人事或雇用事宜相关的行动”予以保密。

      第 2019.06.23.22 – 2019.06.23.24 号决议的理由

      总裁兼首席执行官上任后,将获得基本薪酬以及其薪酬方案中的风险薪酬部分。此薪酬结构今天仍适用。与 ICANN 组织的所有工作人员一样,总裁兼首席执行官亦会受到评估,确定是否达成了其与薪酬委员会和董事会协调设定的具体目标。

      总裁兼首席执行官向薪酬委员会提供了其对 2019 财年目标完成情况的自我评价。进行审核后,薪酬委员会讨论了总裁兼首席执行官的自我评价并对其表示认同。讨论过后,薪酬委员会建议董事会批准向总裁兼首席执行官支付其 2019 财年下半年的风险薪酬。董事会同意薪酬委员会的建议。

      薪酬委员会也讨论了总裁兼首席执行官 2020 财年的一系列风险薪酬部分目标。在对这些目标进行评估之后,董事会承认这些目标十分适当,符合 ICANN 的战略规划和运营规划。

      此项决定有助于推进 ICANN 使命的履行,且符合公共利益,因为它有助于确保总裁兼首席执行官获得与其履行使命的表现相称的报酬,并且表明了其目标符合 ICANN 战略规划和运营规划。

      虽然决定向总裁兼首席执行官支付其 2019 财年下半年的风险薪酬会对 ICANN 产生财务影响,但 2019 财年预算中已考虑了该影响。此项决定不会对域名系统的安全、稳定或弹性产生影响。

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

    2. 高级职员薪酬

      鉴于 ICANN 为其员工提供具有竞争力的薪酬方案对于 ICANN 的运营至关重要。

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

      鉴于薪酬委员会已建议董事会批准下文所示的董事会拟定决议。

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

      兹此发布第 2019.06.23.25 号决议:董事会授予总裁兼首席执行官根据对可比薪酬的独立研究自行决定调整以下人员 2020 财年薪酬的权力,调整后的薪酬方案于 2019 年 7 月 1 生效,且以下人员 2020 财年的基本年薪在现有薪酬基础上的年增长率不得超过 3%:(i) 总法律顾问兼秘书长约翰·杰弗里 (John Jeffrey);(ii) 政策制定支持部高级副总裁戴维·奥利佛 (David Olive);(iii) 高级副总裁兼首席运营官苏珊娜·宾内特 (Susanna Bennett);(iv) 高级副总裁兼首席财务官哈维尔·卡尔维兹 (Xavier Calvez);以及 (v) 工程部高级副总裁兼首席信息官阿什文·兰根 (Ashwin Rangan)。

      第 2019.06.23.26 号决议:董事会批准将总裁兼首席执行官 2020 财年的基本薪酬增加 3%,于 2019 年 7 月 1 生效,并授予总法律顾问兼秘书长根据本决议对总裁兼首席执行官的行政服务协议作出必要修改的权力。

      第 2019.06.23.25 – 2019.06.23.26 号决议的理由

      组织薪酬计划的目标是提供具有竞争力的薪酬方案。组织的一般薪酬理念是为特定职位支付介于 50 至 75 个百分点之间的市场基本薪酬。

      此决议中涉及的每一位高级职员均居住在美国,其中五位生活在大洛杉矶区域,一位生活在哥伦比亚特区。截止 2019 年 5 月,报告的美国通货膨胀率为 2%,而作为生活成本增幅的公认度量标准消费者物价指数 (CPI),大洛杉矶区域的增长率为 3.3%,哥伦比亚特区为 0.7%。

      根据高科技市场的薪酬调查数据2,2019 年功绩调薪预算的 50 分位值为 3.0%。在 ICANN 2019 财年(2018 年 7 月 1 日至 2019 年 6 月 30 日)预算中,所有 ICANN 人员的年度薪酬和绩效评估预算为 2%。尽管如此,大多数高级职员 2019 财年的功绩调薪仅为 1.8%。此外,实际绩效和加薪结果数据显示,总体而言,公司和组织 2018 年的功绩调薪为 3%,总薪酬增长率为 3.4%3

      根据上述经济和薪酬数据,考虑到高级职员的高质量表现,且五年战略和运营规划中确定的活动和举措要求继续保持高层领导的高质量表现,因此有必要对高级职员的薪酬进行审核,使其与市场薪酬水平保持一致。

      ICANN 总裁兼首席执行官已申请向其授予自行增加以下高级职员 2020 财年的基本薪酬的权力:(i) 总法律顾问兼秘书长;(ii) 政策制定支持部高级副总裁;(iii) 高级副总裁兼首席运营官;(iv) 高级副总裁兼首席财务官;以及 (v) 工程部高级副总裁兼首席信息官,且最多在其当前基本薪酬基础上增加 3%。总裁兼首席执行官也已告知董事会,他还打算对不属于高级职员的其他 ICANN 执行团队成员行使这一自由裁量权(这无需董事会批准)。根据 ICANN 薪酬顾问专家提供的可比信息,此处列出的每位高级职员的申请增加额均略低于或未超出组织的既定薪酬惯例。董事会同意总裁兼首席执行官的建议。

      此外,董事会考虑将总裁兼首席执行官的基本工资上调 3%,与已考虑的组织其他高级职员和员工的增长率一致。与考虑其他高级职员时一样,考虑到上述经济和薪酬数据以及总裁兼首席执行官的高质量表现,且五年战略和运营规划中确定的活动和举措要求继续保持高层领导的高质量表现,因此有必要对总裁兼首席执行官的薪酬进行审核,使其与市场薪酬水平保持一致。在考虑此问题时,董事会指出,自 2016 年 5 月开始在 ICANN 任职以来,总裁兼首席执行官的基本工资未曾上调过。因此,尽管需要遵从总裁兼首席执行官的行政服务协议,但他有权与其他组织人员一样定期接受绩效评估。此外,在考虑这些定期评估结果时发现,ICANN 组织所有人员的基本薪酬每年都进行了评估以确定是否需要调整。总裁兼首席执行官也应享受此待遇,这是董事会三年来首次考虑此问题。即便是上调 3%,总裁兼首席执行官的基本工资也仍将低于 ICANN 的目标薪酬范围。因此,董事会批准将总裁兼首席执行官的基本工资上调 3%,于 2019 年 7 月 1 生效。

      依照本决议做出的薪金调整将有助于这些高级职员和组织履行其使命并确保 ICANN 按公共利益行事。

      此决议将对组织造成一定的财务影响,但该影响在 2020 财年预算的预期范围内。此项决议不会对域名系统的安全、稳定和弹性产生直接影响。

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


1 未记录的闭门会议。

2 数据来源:Radford 趋势报告:科技产业 — 全球 2019 年第一季度 (Radford Trends Report Technology Edition- Global Q1 2019)

3 额外的 0.4% 用于宣传和其他细微调整。

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