Skip to main content
Resources

会议记录 | ICANN 董事会特殊会议

本页面还提供其他语种:

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

ICANN 董事会于世界协调时 2020 年 4 月 16 日 15:00 召开了一次电话特殊会议。各位董事放弃了接收有关举行此次会议的通知。

主席玛盾·波特曼 (Maarten Botterman) 准时宣布会议正式开始。

除主席外,以下董事也参加了全部或部分会议:贝基·伯尔 (Becky Burr)、罗恩·达席尔瓦 (Ron da Silva)、萨拉·多伊奇 (Sarah Deutsch)、克里斯·狄思潘(Chris Disspain)、艾芙丽·多利亚 (Avri Doria)、拉斐尔·利托·伊瓦拉 (Rafael Lito Ibarra)、旦科·杰夫托维克 (Danko Jevtović)、马跃然(Göran Marby,总裁兼首席执行官)、曼蒂娜·米斯曼 (Mandla Msimang)、伊哈布·奥斯曼 (Ihab Osman)、奈杰尔·罗伯茨 (Nigel Roberts)、里昂·桑切斯(León Sanchez,副主席)、马修·希尔斯 (Matthew Shears) 以及特里普蒂·辛哈 (Tripti Sinha)。

以下董事因未能参加会议而表示歉意:前村昌纪 (Akinori Maemura)。

以下董事会联络人参加了全部或部分会议:哈罗德·阿维斯特兰(Harald Alvestrand,IETF 联络人)、玛娜尔·伊斯梅尔(Manal Ismail,GAC 联络人)、梅里克·科欧(Merike Käo,SSAC 联络人)以及凯夫·兰吉巴(Kaveh Ranjbar,RSSAC 联络人)。

秘书长:约翰·杰弗里(John Jeffrey,总法律顾问兼秘书长)。

以下 ICANN 高级管理人员和工作人员参加了全部或部分会议:苏珊娜·宾内特 (Susanna Wong Bennett)(王孝蓉,高级副总裁兼首席运营官)、米歇尔·布莱特(Michelle Bright,董事会内容协调主管)、哈维尔·卡尔维兹(Xavier Calvez,首席财务官)、弗兰科·卡拉斯科(Franco Carrasco,董事会运营专家)、曼迪·卡维尔(Mandy Carver,政府与国际政府间组织 [IGO] 合作高级副总裁)、莎莉·纽厄尔·科亨(Sally Newell Cohen,全球传播高级副总裁)、戴维·康纳德(David Conrad,首席技术官)、金·戴维斯(Kim Davies,IANA 服务副总裁)、莎曼·艾斯内(Sam Eisner,副总法律顾问)、丹·哈洛伦(Dan Halloran,副总法律顾问)、杰米·赫德伦(Jamie Hedlund,合同合规和消费者保护高级副总裁兼华盛顿哥伦比亚特区办公室总经理)、约翰·杰弗里(John Jeffrey,总法律顾问兼秘书长)、亚伦·吉美内兹(Aaron Jimenez,董事会运营专家)、茜拉·琼森(Sheila Johnson,副总法律顾问)、温西安·科尼格斯菲尔德(Vinciane Koenigsfeld,董事会运营高级主管)、卡伦·伦兹(Karen Lentz,政策研究和数据服务高级主管)、戴维·奥利佛(David Olive,政策制定支持部高级副总裁)、温迪·普若菲特(Wendy Profit,董事会运营高级经理)、埃里卡·兰德尔(Erika Randall,助理总法律顾问)、阿什文·兰根(Ashwin Rangan,工程部高级副总裁兼首席信息官)、丽莎·莎莉诺(Lisa Saulino,董事会运营专家)、艾米·斯塔索斯(Amy Stathos,副总法律顾问)、特里莎·斯旺哈特(Theresa Swinehart,多利益相关方战略和战略计划高级副总裁)、鲁斯·维恩斯坦(Russ Weinstein,通用顶级域客户与服务高级主管)以及吉娜·比亚维森西奥(Gina Villavicencio,全球人力资源部高级副总裁)。

  1. 主要议程:
    1. 密钥签名密钥仪式的应急计划
    2. 公共利益注册管理机构 (PIR) 控制权变更
  1. 主要议程:

    1. 密钥签名密钥仪式的应急计划

      主席介绍了该议程项目并指出,鉴于 COVID-19 疫情大流行,董事会正在考虑下一次密钥签名仪式的应急计划。他解释说,密钥签名仪式可生成加密签名,从而允许使用 DNSSEC 对根区域进行适当的验证,它以高度透明和负责任的方式举行,参与者包括来自世界各地的受托社群代表。该仪式通常每三个月举行一次,按照 DNSSEC 实践声明的规定进行。

      由于世界上许多司法管辖区因 COVID-19 疫情而发布了旅行限制令和保持社交距离的指令,这对仪式的总体执行方式带来了一些挑战。主席指出,考虑到这些挑战,ICANN 组织已经制定了一系列举行仪式的方案。他强调,这些计划是经过与受托社群代表和更广泛的运营社群讨论而制定的,是在当前形势下维持利益相关方信任的最佳权宜之计。

      董事会讨论了举行密钥签名仪式的计划。罗恩·达席尔瓦询问 RSSAC 或 SSAC 是否就应急计划中所述的方法发表了任何意见,戴维·康拉德和金·戴维斯向董事会汇报了 ICANN 组织围绕应急计划开展的外展工作的最新情况。他们指出,SSAC 的一些个人会员发表了意见,并且这些计划也已提交给了根区发展审核委员会 (RZERC)。另外,会议还讨论了由域名系统运营、分析和研究中心托管的 DNS 运营电子邮件清单。ICANN 组织开展了适当的工作来回应这些意见。

      哈罗德·阿维斯特兰询问在当前形势下可能会选择应急计划中的哪个方案,金 (Kim) 指出,鉴于当前形势,提议按照方案 C 所述推进仪式。利托·伊瓦拉询问了用于解释仪式举行方式的任何变更的宣传计划。

      马修·希尔斯询问受托社群成员是否可以远程参与,金解释了目前所采取的措施,这些措施旨在确保远程与会者有机会更积极地参与其中,从而确保他们能够在该仪式方面保持参与。

      特里普蒂·辛哈提出决议提案并得到利托·伊瓦拉的支持。经过讨论,董事会采取了以下行动:

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

      鉴于 2019 年 12 月,一种引发 COVID-19 疾病的新型冠状病毒出现,并在 2020 年 1 月 30 日被世界卫生组织 (WHO) 宣布为国际关注的突发公共卫生事件。2020 年 3 月 11 日,WHO 公开宣布 COVID-19 为全球大流行病。

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

      鉴于为了应对 COVID-19 疫情,ICANN 制定了几项应急计划,决定采用一套渐进式的方法来举行密钥仪式,最初的方案会尽量让更多人员参与,如果无法参与,则会制定一系列渐进式的替代方案。

      鉴于能否在今年晚些时候有序地举办随后的仪式仍然具有很大的不确定性,我们正在考虑其他一些方案,即举办仪式来生成涵盖更长一段时间的加密签名,从而降低此风险。

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

      出席会议的所有董事会成员一致投票赞成第 2020.04.16.01 号决议。前村昌纪未能对该决议投票。决议通过。

      第 2020.04.16.01 号决议的理由

      1. 简介

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

        由于 2020 年的新冠疫情,ICANN 组织员工的流动性受到了限制,提供这些受托角色的其他公司也在颁布类似的政策。此外,各国政府也相继出台了旅行限制令,这同样减少了人员的流动性。有一个很大的风险是,这些事件使参与者的人数低于最低人数要求,进而会损害 KSK 的管理。如果缺乏有效的应急计划,便无法成功执行 KSK 操作,最终将导致 DNS 出现大规模的灾难性故障。

      2. 董事会职权范围

        董事会对此问题所采取的行动与先前对 DNSSEC 密钥签名密钥的运作所做的决策保持一致,可能会给社群带来广泛的影响。过去,ICANN 曾采纳过一项决议,授权继续进行首次密钥签名密钥轮转。

      3. 提案

        董事会目前采取的行动是,授权总裁兼首席执行官与 IANA 服务副总裁协商,采取所有必要措施来实施以下应急计划中所述的密钥签名仪式。应急计划中的仪式管理方法包含两个关键部分:

        1. 采用渐进式的方法举行仪式,最初的方案会尽量让更多人员参与,如果无法参与,则会制定一系列渐进式的替代方案。
        2. 力求实施一项应急计划,在下次的仪式上为更多季度提供签名,这将给运营提供一定的弹性,以应对充满不确定性的形势。

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

        3.1 举行第 41 次 KSK 仪式的计划方案

        渐进式方法包含四个方案,按最理想的情况到最不理想的情况排列。每个方案都设有相关的条件和批准流程,满足后才能转至下一个方案:

        3.1.1 方案 A:按原定计划举办 2020 年 4 月的仪式

        第 41 次 KSK 仪式目前定于 4 月 23 日在弗吉尼亚州库尔佩珀举行。如果出席人数达到最低人数要求,其中应包含三名受托社群代表,则可按照正常程序继续在该日期举行仪式。

        主要风险:仪式是否可按原定计划举行取决于受托社群代表的国际流动性,目前他们的出行均受到了严重影响,而这些出行限制在今后会如何变化也难以预测。员工在国内的流动性也受到了影响。

        转为方案 B:如果根据 IANA 服务副总裁的判断,虽然形势无法稳定下来,但能够高度确定仪式可以如期举办,那么方案 B 将成为首选。

        3.1.2 方案 B:举行仪式,并且只选择美国的人员参加

        在库尔佩珀举行的仪式中,七个受托社群代表中有三个位于美国,其中两个位于东海岸,一个位于西海岸。三位中只有两位可以参加在选定日期举行的仪式,因此这个方案将确定一个备选日期,以便三人均可参加。

        主要风险:此方案取决于受托社群代表和员工在国内的持续流动性。还必须假定必要人员不会生病或因其他原因不能参加,因为该方案没有制定有人缺席时的备用计划。

        转为方案 C:如果根据 ICANN 总裁的判断,可以高度确定仪式无法举办或者因为其他原因无法在 5 月 8 日前举办,那么方案 C 将成为首选。

        3.1.3 方案 C:举行仪式,并且只选择位于洛杉矶的人员参加,而且出席人数刚好达到最低人数要求。

        KMF 被特意设计为允许在灾难恢复仪式中只需工作人员出席仪式,以确保能够根据需要举办密钥仪式。达到最低人数要求的工作人员可以在短时间内在埃尔塞贡 KMF 举行密钥仪式。然而,这个方案对受信社群代表亲自出席的人数不做限制。

        主要风险:此方案对工作人员和承包商亲自参与(即未丧失行动能力或行动未受限)的人数设有最低要求。它违反了参加密钥仪式的标准要求,但在灾难恢复程序范围内,它被视为其中的一个方案。

        转为方案 D:如果仪式不能在 6 月 19 日之前举行,则方案 D 将成为最终选择。ICANN 董事会将做出采用方案 D 的最终决定。

        3.1.4 方案 D:暂停签署 DNS 根区

        如果想不到任何方法来激活 KSK 并执行签名操作,那么这是最后的选择。必须立即进行大规模的教育活动,指导解析器运营商禁用 DNSSEC 验证。由于无法确保在全球范围内实施,因此出现大规模中断的风险很高,而高风险将对 DNSSEC 作为一种技术所受到的信任造成致命性的伤害。

        大家都认为此方案实施的可能性很低,尽管如此,这确实是最终方案。如果不执行方案,在没有进行成功的密钥签名仪式的情况下,从 2020 年 7 月起,DNSSEC 验证将失败。

        3.2 签署涵盖两个季度的密钥材料

        一次标准的密钥仪式一般会生成涵盖一个季度(3 个月)的签名。在本次密钥仪式中生成涵盖更多季度的签名,将在未来充满不确定性的时期为根区运营提供更大的弹性。如果出现了长期威胁,我们可视需要利用这段时间考虑对当前的密钥仪式模式进行长期更改。

        根据受托社群代表的反馈,我们预计将为三个季度、共计九个月生成签名。这样一来,在 2020 年剩余时间内将无需举行密钥签名仪式,而且下一次签名仪式在 2021 年 2 月左右举行即可。额外季度的密钥材料将由 ICANN 安全保管,并根据正常的时间表发给根区维护人。

      4. 利益相关方协商

        在筹备这个方法的过程中,工作人员与以下人员或机构进行了互动:

        • 计划参加 2020 年 4 月仪式的人员;
        • 第三方审计机构;
        • 根区维护人;
        • 支持密钥仪式的供应商;
        • 受托社群代表和之前出席仪式的人员;
        • ICANN 的根区发展审核委员会,该委员会的成员包括来自 ICANN 各主办组织和咨询委员会的代表;以及
        • DNS-OARC 运营电子邮件清单;以及
        • KSK 轮转项目电子邮件清单。

        此方法的例行通知也发到了我们的公告电子邮件清单,该清单中大约有 700 个对根 KSK 管理感兴趣的订阅者。

        讨论的焦点是提案要素的可行性,它们对运营和控制环境的影响,以及为了保持 ICANN 在管理 KSK 方面所享有的较高信任度而需采取的措施。

      5. 财务影响

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

      6. 公众协商要求

        此问题与 IANA 域名职能运营有关。在 KSK 运营中使用的程序必须获得政策管理机构的批准,该机构是 ICANN 组织内部的一个委员会。没有制定正式的公众意见要求,但是 IANA 工作人员将继续与受托社群代表及其他利益相关方协商,以实施和适当修改这些计划。我们将制定一项沟通策略,帮助大家了解任何运营上的变化和影响。

      7. 公共利益

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

      8. 主要风险

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

        8.1 参与者的出行受到限制

        该计划要解决的主要风险是参与者无法出席密钥仪式。建议的解决方案是采用渐进式的方法,采用不同的方案举办仪式,包括仅与洛杉矶都会区的工作人员举行仪式,这样一来便无需搭乘飞机或跨州出行。

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

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

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

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

        8.4 工作人员生病或身体不适

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

        8.5 方案 C 破坏了社群对 KSK 管理权的信任

        在没有采取标准保护措施(包括第三方社群见证人亲自出席 KMF)的情况下,举行仪式可能会降低社群对 KSK 管理和管理权的信任度。为了解决这个问题,仪式将在第三方审计员的监督下按照审计标准举行,且所有材料(包括综合审计录像和仪式上所用的材料)将按标准在线发布。我们将提供并优化仪式的现场直播,让不能到场的人员观看并提出问题或疑问。我们已就如何举行方案 C 的仪式咨询了 TCR 及其他利益相关方,所以仪式已经在有必要限制的情况下,最大限度满足了他们的要求。我们将努力获得 TCR 及其他利益相关方的认同,让他们知道这个方案已经是备选方案中的最佳方案了。

    2. 公共利益注册管理机构 (PIR) 控制权变更

      该议项已从议程中删除。

    主席宣布会议结束。


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