Skip to main content
Resources

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

本页面还提供其他语种:

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

  1. 认可议程:
    1. 任命根服务器系统咨询委员会 (RSSAC) 主席
    2. 安全与稳定咨询委员会 (SSAC) 成员任命
    3. 2021 年密钥签名密钥仪式的应急计划
    4. 更改信用卡支付处理服务协议
  2. 主要议程:
    1. 2020 年战略前景趋势报告
    2. ICANN 组织风险偏好声明
    3. Afilias 控制权变更审批申请
    4. 其他事务
  3. 执行会议:
    1. 2021 财年上半年总裁兼首席执行官风险薪酬

  1. 认可议程:

    1. 任命根服务器系统咨询委员会 (RSSAC) 主席

      鉴于《ICANN 章程》要求成立根服务器系统咨询委员会 (RSSAC),负责就互联网根服务器系统的运营、管理、安全性和整合性相关问题向 ICANN 社群和 ICANN 董事会提供建议。

      鉴于《ICANN 章程》要求 ICANN 董事会任命 RSSAC 主席。

      鉴于 RSSAC 经过了 30 天的提名期以筹备 RSSAC 主席选举。

      鉴于弗莱德·贝克 (Fred Baker) 是唯一的候选人,并于 2020 年 12 月 1 日以口头表决的方式再次当选。

      鉴于 RSSAC 已建议 ICANN 董事会任命弗莱德·贝克担任 RSSAC 主席。

      兹此发布第 2020.12.17.01 号决议:ICANN 董事会任命弗莱德·贝克为 RSSAC 主席,任期截止日期为 2022 年 12 月 31 日。

      第 2020.12.17.01 号决议的理由

      2019 年 9 月,ICANN 董事会批准了一项关于 RSSAC 领导层的章程修订。因此,RSSAC 的领导层构架从两名联合主席过渡为一名主席和一名副主席。现任 RSSAC 主席弗莱德·贝克的任期截止日期为 2020 年 12 月 31 日。

      除了在编制预算时已经考虑到的用于持续支持 RSSAC 的资源以外,任命 RSSAC 联合主席预计不会对 ICANN 组织产生任何其他财务影响。

      该决议属于组织管理职能,无需征询公众意见。RSSAC 主席的任命有助于 ICANN 组织实现加强 DNS 安全、稳定与弹性的承诺,且符合公共利益和 ICANN 的使命。

    2. 安全与稳定咨询委员会 (SSAC) 成员任命

      鉴于《ICANN 章程》为 SSAC 成员规定了三年的任期,并要求 SSAC 通过其内部流程向 ICANN 董事会提出有关这些任期的任命建议。

      鉴于 2020 年 11 月,SSAC 成员资格委员会对任期将于 2020 年 12 月 31 日结束的 SSAC 两名成员进行了一次年度审核,并于 2020 年 12 月向 SSAC 提交了有关成员连任的建议。

      鉴于 2020 年 12月 14 日,SSAC 成员批准了成员连任建议。

      鉴于 SSAC 建议董事会再次任命以下 SSAC 成员,任期为 3 年:蒂姆·阿普利 (Tim April) 和安德烈·克莱斯尼科夫 (Andrei Kolesnikov)。

      鉴于 SSAC 成员资格委员会代表 SSAC 建议董事会任命马修 托马斯 (Matthew Thomas) 到 SSAC 任职,任期为三年,从 2021 年 1 月 1 日上任,至 2023 年 12 月 31 日结束。

      兹此发布第 2020.12.17.02 号决议:董事会接受 SSAC 的建议,再次任命以下 SSAC 成员,任期为三年,从 2021 年 1 月 1 日上任,至 2023 年 12 月 31 日结束:蒂姆·阿普利 (Tim April) 和安德烈·克莱斯尼科夫 (Andrei Kolesnikov)。

      兹此发布第 2020.12.17.03 号决议:董事会接受 SSAC 的建议,任命马修 托马斯为 SSAC 主席,任期为三年,从 2021 年 1 月 1 日开始,至 2023 年 12 月 31 日结束。

      第 2020.12.17.02 – 2020.12.17.03 号决议的理由

      SSAC 是一个多样化的社群,其成员具备特定主题的专业知识,使 SSAC 能够履行其职责和使命。SSAC 自成立以来已邀请在技术和安全领域有渊博知识和丰富经验的成员加入其中,他们的知识和经验对互联网名称和地址分配系统的安全性和稳定性至关重要。

      SSAC 能否作为合格的主体持续运营取决于同意自愿投入时间和精力来执行 SSAC 使命的优秀主题问题专家是否增加。

      该决议属于组织管理职能,无需征询公众意见。SSAC 成员的任命符合公共利益并进一步推进了 ICANN 的使命,因为它有助于 ICANN 实现加强 DNS 安全、稳定与弹性的承诺。

    3. 2021 年密钥签名密钥仪式的应急计划

      鉴于 ICANN 必须通过其附属 PTI 定期生成加密签名,以允许使用 DNSSEC 对根区进行适当的验证。目前,这项工作采用"密钥签名仪式"的形式每三个月进行一次,来自全球各地的受托社群代表将参与仪式,此工作受到 DNSSEC 实践声明的约束。

      鉴于 2020 年 4 月,董事会决定授权应急计划并采取经修改的形式举办仪式,以此应对 COVID-19 疫情带来的挑战。

      鉴于国际旅行限制令以及政府和卫生当局发布了限制聚会的指令,COVID-19 疫情持续给 ICANN 依照政策举行密钥仪式带来了挑战。

      兹此发布第 2020.12.17.04 号决议:董事会认为应急计划仍然符合 ICANN 的最佳利益,并符合全球公共利益,董事会授权总裁兼首席执行官或其指定人员在与 PTI 总裁协商后,于 2021 年期间采取所有必要步骤按照应急计划所述举行密钥签名仪式。

      第 2020.12.17.04 号决议的理由

      1. 简介

        根区密钥签名密钥(根 KSK)使用一种系统进行管理,该系统会故意从逻辑和地理层面分散多个受托角色,以此作为一种安全措施,目的是降低不同的相关方执行意外活动造成冲突的风险。在正常情况下,许多受托角色扮演者需要在 ICANN 管理的两个站点(安全密钥管理设施,缩写为 KMF)之一汇合以举行"仪式",在仪式上,他们将履行职责执行必要的 KSK 程序,仪式通常每三个月举行一次。

        由于新冠疫情,ICANN 组织员工的流动性受到了限制,提供这些受托角色的其他公司已颁布类似的政策。此外,各国政府也相继出台了旅行限制令,这同样减少了人员的流动性。这些因素很可能会持续妨碍我们正常举行密钥签名仪式。如果缺乏有效的应急计划,便无法成功执行 KSK 操作,最终将导致 DNS 出现大规模的灾难性故障。

      2. 董事会职权范围

        董事会对此问题所采取的行动与 2020 年 4 月疫情初期所做的决策保持一致。此决策旨在将应急计划延长至原定期限之后。

      3. 提案

        董事会目前采取的行动是,授权 ICANN 总裁兼首席执行官与 PTI 总裁协商,继续采取所有必要措施来实施以下应急计划中所述的密钥签名仪式。应急计划中的仪式管理办法可供继续调整仪式的运营,以促进参与过程实现最高安全性;对于无法参与的地区,则制定替代方案。该管理办法还增强了运营弹性,可针对更多季度执行签名操作,直到仪式可以安全恢复正常运营形式。

        2020 年 4 月 6 日召开的 ICANN 政策管理机构会议批准了在调整后以此形式进行运营的相关程序和政策。具体而言,DNSSEC 实践声明1 (DPS) 正式规定了执行 KSK 管理的方式,并经过了修改,以允许在获得管理层的适当授权后实施呈递的方案。

        3.1 KSK 仪式 42(2021 年第一季度)

        员工吸取了计划和举行 KSK 仪式 41 的经验教训,根据社群反馈改进了方案细节,并提议以类似方式举行 KSK 仪式 42,以满足更广泛的互联网社群和我们的 DPS 要求。仪式将于 2021 年第一季度举行,至于准确日期,我们将在此决议通过后,通过对潜在与会者进行民意调查来确定。

        3.1.1 循序渐进的仪式举行方案

        与 2020 年 4 月举行的第 41 次 KSK 仪式一样,我们将对一系列方案的可行性进行评估,然后确定最终的仪式配置。这些方案将根据仪式举行时间的限制情况,提供多种候补人员组合。在所有情况下,仪式将继续以公开透明的方式举行,社群成员可以通过远程方式参与,以对仪式的举行方式保有信心。我们将通过实施有效的补充措施,切实保障仪式中需要使用的所有安全要素。

        3.1.2 为更多季度执行签名操作

        预计到 2021 年,新冠疫情仍将对运营产生重大影响。为降低对每季度举行重要仪式的影响,该计划还为签名操作提供了 9 个月的延长时间。这样一来,在 2021 年第四季度之前将无需举行密钥签名仪式。

        3.2 KSK 仪式 43(2021 年第四季度)

        2021 年第一季度仪式若能成功举行,将产生有效期达 9 个月的签名,而下一次密钥仪式将在 2021 年第四季度举行。

        员工将继续监测疫情带来的影响,并循序渐进地为本次仪式可能出现的各种情况做好准备。如果大规模接种疫苗计划被证实有效,国际旅行限制被放宽,那么 2021 年底的仪式将有望在国际社会中以面对面的形式参与,即以正常形式举行。

      4. 利益相关方协商

        最初的应急计划于 2020 年初由大量社群参与制定,包括预期的仪式参与者、第三方审计机构、根区维护人、支持密钥仪式的供应商、受托社群代表和之前出席仪式的人员、ICANN 的根区发展审核委员会和多个相关的行业电子邮件清单。在 2020 年 4 月的仪式之后,收到的反馈大多比较积极,大家认为修改后的形式在实现目标的同时,还维持了社群对 KSK 管理层的信任。

        许多利益相关方已知悉我们打算将应急计划延长至 2021 年,并表示支持这项工作。

      5. 财务影响

        除了与 KSK 管理有关的正常运营成本外,该提案预计不会对财务产生重大影响。

      6. 公众协商要求

        此问题与 IANA 域名职能运营有关,根据与 ICANN 签订的合同由 PTI 执行。在 KSK 运营中使用的程序必须获得政策管理机构的批准,该机构是 ICANN 组织内部的一个委员会。没有制定正式的公众意见要求,但是 IANA 员工将继续与受托社群代表及其他利益相关方协商,以实施和适当修改这些计划。

      7. 公共利益

        董事会的行动符合公共利益和 ICANN 的使命,因为它有助于继续确保互联网唯一标识符系统的稳定和安全运营。无法及时举行密钥签名仪式可能导致 DNSSEC 停止运行,进而引起全球 DNS 解析出现大规模失败。董事会的行动有助于确保启用 DNSSEC 的设备能够解析任何域名。

      8. 主要风险

        董事会在审议此行动时考虑了以下风险因素。

        8.1 参与者的出行受到限制

        该计划要解决的主要风险是参与者无法以安全的方式出席密钥仪式。建议的解决方案是循序渐进地采用不同的方案举办仪式,包括仅与洛杉矶都会区的员工举行仪式,这样一来便无需搭乘飞机或跨州出行,同时每位与会者都应采取安全预防措施。

        8.2 设施运营商暂时不准任何人进入设施

        为 KMF 提供设施的公司可能会因为疫情的关系而暂时不准任何人进入设施。建议的解决方案是向其高级管理层(如有必要,可通过受信任的代理人)提出建议,请求对此进行例外处理,因为我们确实需要举行这一仪式以支持关键的互联网基础设施和互联网运作。ICANN 已经在与地方和国家/地区权威机构讨论,如果有必要保留举行密钥仪式所需的访问权限,则颁布特殊指导意见。

        8.3 政府暂时不准许进入设施,及/或限制出行

        各级政府可能会对旅行或聚会实行限制,这会妨碍我们举行仪式。ICANN 可以通过适当的渠道建议政府作出例外处理(如上一节所述),并指出确实需要举行这一仪式以支持关键的互联网基础设施和互联网运作。特别是,ICANN 可以利用与政府之间建立的关系来寻求此类豁免。

        8.4 员工生病或身体不适

        如果因为员工生病、被隔离或无法出席,导致未能达到员工的最低人数要求,则无法举行仪式。主要的解决方案是,PTI 员工和其他来自 ICANN 组织的支持人员从 2020 年 3 月开始,便一直遵守保持社交距离的指令,以限制潜在的疾病传播。此外,大约有三个月的窗口期可用来审阅所提出的备选方案,并有足够的时间来调整每个备选方案中的确切日期,以允许恢复和继续举行。人员配置考虑也非常周全,如果需要,关键角色可以由不同的人员来履行职责。

    4. 更改信用卡支付处理服务协议

      鉴于 ICANN 已确定需要签订一份新的信用卡支付流程合同,并获得了 [出于谈判目的已删减] 的支持。

      鉴于董事会财务委员会已审核与 [出于谈判目的已删减] 签订合同所带来的财务影响。

      鉴于组织和董事会财务委员会都建议董事会授权主席兼首席执行官或其指定人员采取所有必要行动与 [出于谈判目的已删减] 签署新合同并根据该合同支付所需款项。

      兹此发布第 2020.12.17.05 号决议:董事会授权总裁兼首席执行官或其指定人员采取一切必要行动与 [出于谈判目的已删减] 签署新合同并根据该合同支付所需款项。

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

      第 2020.12.17.05 – 2020.12.17.06 号决议的理由

      ICANN 组织自 2007 年 9 月起就已与 [出于谈判目的已删减] 合作处理信用卡支付事项。多年来,ICANN 通过信用卡获得的收款量有所增加,而 2007 年商定的分级费率结构对 ICANN 的优惠力度已不足够。然而,ICANN 希望继续通过长期合作伙伴和可信服务提供商 [出于谈判目的已删减] 向其利益相关方提供此类便捷的付款方式。

      为了从 10 个被提名人和 3 个参与者中确定潜在的服务提供商,ICANN 启动了一项正式的提案征询 (RFP),并最终确定在新的费率结构下,[出于谈判目的已删减] 不仅可为我们节约最多成本,还能提供最佳的产品价值。

      选择 [出于谈判目的已删减] 涉及的过渡工作量最少,而且该组织在开证银行和 ICANN 之间转移资金的记录一直良好,从未出现过延迟或争议现象。[出于谈判目的已删减] 还符合 ICANN 的三个主要目标:

      1. 提供遵守全球和当地法律法规的安全服务。
      2. 降低 ICANN 与信用卡商户费用相关的成本。
      3. 迁移到支付网关服务,提高信用卡支付的效率和准确性。

      ICANN 还就优惠条款进行了谈判。新合同的初始期限为三年,自动续签期为一年。双方可在提前 60 天发出通知的情况下随时取消合同。[出于谈判目的已删减] 的费用在合同期限内是固定的,不会出现费用增加的情况。

      经过仔细分析,董事会与该组织达成一致,认为新合同在目前而言是性价比更高的信用卡付款解决方案。董事会了解到,该组织将继续审核其他付款方式,以进一步减少这些服务的相关费用,而且还将定期执行审核流程,以便审核服务提供商的费用收取情况。

      以优惠条款履行该合同符合公共利益,因为这将在不影响 ICANN 向其社群提供服务的情况下降低开支,而且也符合 ICANN 的使命。

      这将带来积极的财务影响,因为新合同将显著降低信用卡的手续费。此举预计不会对域名系统的安全、稳定与弹性产生影响。

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

  2. 主要议程:

    1. 2020 年战略前景趋势报告

      鉴于在 2019 年 11 月至 2020 年 3 月期间收到社群和 ICANN 组织对未来几年间可能影响 ICANN 的主要趋势的意见后,董事会进行了分析并发现,无需对《2021-2025 财年战略规划》中体现的 ICANN 战略目标作出更改。

      鉴于董事会于 2020 年 10 月 22 日成立了一个战略规划委员会来监督年度战略前景(趋势)流程,以便确定相关趋势和活动,为 ICANN 的战略规划和重要工作提供参考。在此之前,董事会依赖于通过董事会战略规划工作组开展这些工作。在 ICANN 组织的支持下,此工作组在审核与分析趋势工作的结果及其相关机遇、风险和对 ICANN 的影响方面发挥了核心作用。此工作组负责将其工作成果阐述为一系列拟议的工作重点趋势、相关影响和相关的战略和/或战术建议,供全体董事会考量。

      鉴于 ICANN 董事会和 ICANN 组织的成员于 2020 年 10 月 6 日与社群举行了一场网络研讨会,期间演示了进行战略前景分析的流程和方法。

      兹此发布第 2020.12.17.07 号决议:董事会确认 ICANN《2021-2025 财年战略规划》将维持效力并保持不变,因此目前无需对该战略规划作出重申声明。

      兹此发布第 2020.12.17.08 号决议:董事会认识到,未来可能需要修订该战略规划,以便解决比如在更新 ICANN 的五年运营和财务规划期间确定的现实资金问题,或者需要在此战略规划的生命周期内进行中期修订。如需这类改变,董事会届时将就进一步行动范围向 ICANN 组织作出指示。

      第 2020.12.17.07 – 2020.12.17.08 号决议的理由

      2019 年 6 月 23 日,董事会采纳了 ICANN《2021-2025 财年战略规划》并指出,ICANN 应与社群持续开展年度规划协商,确保 ICANN 规划的年度编制考虑各种新趋势或现有趋势的变化。这些工作均在战略前景趋势识别流程下执行。

      战略前景趋势识别是一个年度流程,可确保 ICANN 以一致的方式识别和跟踪趋势;为迎接机遇做好准备;缓解或规避风险;为战略和运营规划及重点工作提供参考。

      这项工作需要 ICANN 组织、社群和 ICANN 董事会携手合作,以应对影响 ICANN 的新兴事物或不断变化的趋势。趋势表明事物发展或演变的总体方向,这些方向已经或可能对 ICANN、ICANN 的使命、运营或其生态系统产生影响。因为 ICANN 在市场中运营,所以其趋势具有多种形式,其中包括内外部、特定于组织的、与社区相关的趋势,甚至还可能超出 ICANN 的生态系统。

      ICANN 组织发现,这项活动有助于揭示未来的机遇和挑战、为规划提供参考、帮助考量重点工作和进行风险管理。

      2019 年 11 月至 2020 年 3 月期间,ICANN 组织共计召开了 21 次战略前景趋势识别会议,来自社群和组织的 398 名参与者参加了会议,共收集了 1,853 个数据点。社群会议成果已发布在 icann.org 网站的战略规划页面。

      2020 年 4 月至 9 月期间,董事会战略规划工作组在 ICANN 组织的支持下,对收到的趋势会议数据进行了深度分析,其中包括评估趋势、风险、机会和对 ICANN 的潜在影响。本文所附的 2020 年战略前景趋势报告中记录了此分析和相关建议的详情,以供参考。

      董事会战略规划委员会根据董事会战略规划工作组在委员会成立之前完成的工作,建议保持 ICANN《2021-2025 财年战略规划》不变,因此目前无需对该战略规划作出重申声明。

      预计此决议不会对 ICANN 产生财务影响,不过 ICANN 运营规划可能由此发生一些变更,而那些变更在通过批准后可能会产生一定的财务影响。这项行动预计会对域名系统 (DNS) 的安全、稳定与弹性产生积极影响,因为它将继续支持 ICANN 在该领域的战略工作。

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

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

      如上所述,这是一项组织管理职能,须经过社群意见征询,但无需进一步征询公众意见。

    2. ICANN 组织风险偏好声明

      鉴于 ICANN 董事会先前已认可风险管理框架的益处和必要性,认为该框架能够指导 ICANN 组织管理其面临的风险。

      鉴于 ICANN 董事会先前为风险管理框架设定了目标模型,其中包含一份风险偏好声明。

      鉴于风险管理与确定组织的薄弱点相关,因此公开发布风险偏好声明是欠妥的举动。

      兹此发布第 2020.12.17.09 号决议:董事会批准 ICANN 组织风险偏好声明并指示总裁兼首席执行官或其指定人发布一份总结摘要。

      第 2020.12.17.09 号决议的理由

      这份风险偏好声明阐述了 ICANN 组织在广泛层面上为履行其使命而愿意承担和保留的风险等级。

      ICANN 组织风险偏好声明:

      • 倡议员工在可接受的风险限度内追求目标。
      • 为规划和预算重点工作提供意见。
      • 指导董事会及其决策工作,并作为董事会决议的依据之一。
      • 为绩效管理和激励措施提供参考,并指导员工根据组织的风险偏好做出决策。
      • 鼓励风险管理而不是规避风险的文化,使风险管理成为整个组织的共同责任,所有员工都要对此负责。
      • 通过证明组织致力于积极管理风险来提高 ICANN 的声誉。

      ICANN 董事会和 ICANN 高管团队要求为 ICANN 组织制定并实施稳健的风险管理框架。在风险管理目标运营模式下,风险偏好声明是成熟框架的一部分。

      董事会和 ICANN 组织高管团队负责明智地设定可接受的风险等级。风险偏好声明规定了组织愿意承担和保留的风险,可表明 ICANN 领导层的风险偏好,他们将根据这些风险偏好来指导 ICANN 的运营。

      请注意,任何风险偏好声明均旨在就组织面临的风险提供概括性表述。其目的是提供一个简要概述,供所有人员和董事会参考。此外,风险通常与组织的薄弱点或面临的威胁相关,故而任何组织公开此类风险的细节都是欠妥的举动。

      风险偏好声明由组织的风险管理职能部门与组织各职能部门的代表合作制定。风险偏好声明由组织高管团队审核、由 ICANN 总裁兼首席执行官批准,并由董事会风险委员会考量。董事会风险委员会审核并建议董事会批准 ICANN 组织风险偏好声明。董事会在 2020 年早些时候收到了关于风险偏好声明的介绍。

      采纳风险偏好声明符合公共利益,也完全符合 ICANN 的使命,因为它阐明了 ICANN 领导层的风险偏好,从而可以从风险管理的角度提高 ICANN 组织的运营效率,并通过始终如一的方式指导 ICANN 组织的运营。

      采纳 BRC 的建议预计不会对 ICANN 产生其他财务影响;它正式确立了 ICANN 组织的风险管理框架,并加强了管理风险的方法,因此可能对域名系统的安全、稳定与弹性产生积极影响。

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

    3. Afilias 控制权变更审批申请

      未达成任何决议。

    4. 其他事务

      未达成任何决议。

  3. 执行会议:

    1. 2021 财年上半年总裁兼首席执行官风险薪酬

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

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

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

      第 2020.12.17.10 号决议的理由

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

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

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

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


1 https://www.iana.org/dnssec/dps

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