Skip to main content
Resources

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

本页面还提供其他语种:

  1. 认可议程:
    1. 批准会议记录
    2. 安全与稳定咨询委员会任命
    3. 开展首轮 IANA 域名职能审核
    4. .coop TLD 注册管理机构协议续约
    5. 任命 2019 年提名委员会主席和候任主席
  2. 主要议程:
    1. GAC 建议:巴拿马公报(2018 年 6 月)
    2. 根服务器战略
    3. 继续进行 KSK 轮转
    4. 进一步考量 .AMAZON 申请
    5. 其他事务

 

  1. 认可议程:

    1. 批准会议记录

      第 2018.09.16.01 号决议:理事会批准 2018 年 7 月 18 日和 8 月 21 日的 ICANN 董事会会议记录。

    2. 安全与稳定咨询委员会任命

      鉴于安全与稳定咨询委员会 (SSAC) 审查了成员资格,并适时做出了调整。

      鉴于 SSAC 成员资格委员会代表 SSAC 要求董事会任命戴维·匹萨特洛 (David Piscitello) 到 SSAC 任职,自董事会批准之日起即刻生效,至 2020 年 12 月 31 日止。

      兹此发布第 2018.09.16.02 号决议:董事会任命戴维·匹萨特洛到 SSAC 任职,自董事会批准之日起即刻生效,至 2020 年 12 月 31 日止。

      第 2018.09.16.02 号决议的理由

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

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

      在 40 年的职业生涯中,戴维在网络、安全、互联网协议和服务方面积累了丰富的经验。戴维在 2005-2018 年间担任 ICANN 员工,最近的职位是安全和 ICT 协调副总裁,多年来为 SSAC 的工作提供支持。他与时任主席史蒂芬·克罗克 (Stephen Crocker) 博士合作,开展研究并代表委员会撰写了技术报告和公告。他为许多 SSAC 讨论做出了积极贡献。

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

    3. 开展首轮 IANA 域名职能审核

      鉴于《ICANN 章程》要求“董事会或其相应的委员会根据 IANA 域名职能合同中规定的合同要求以及根据《ICANN 章程》第 18 条确定的由 IANA 职能审核小组(“IFRT”)执行的 IANA 域名职能 SOW,对 PTI 在履行 IANA 域名职能方面的表现进行定期和/或特定审核(各项此类审核分别称为“IFR”)”。

      鉴于《ICANN 章程》第 18.2.a 款要求开展首次定期 IFR 的时间不得迟于 2018 年 10 月 1 日。

      鉴于《ICANN 章程》第 18.7 款规定了 IFRT 的组成,并要求根据任命组织的规则和程序任命审核小组的成员和联络人。

      鉴于某些任命组织已经任命了 IFRT 的成员和联络人。

      鉴于《ICANN 章程》第 18.8.c 款要求 IFRT 成员和联络人的任命组织开展合作,使组建的审核小组在多样性(包括职能、地理和文化多样性)和技能方面取得平衡,并力求增加参加各项审核的个人的数量;但前提是,审核小组应包括来自各个 ICANN 地理区域的成员,并且 ccNSO 和注册管理机构利益相关方团体不应任命多个来自相同 ICANN 地理区域的国家的公民担任成员。

      鉴于《ICANN 章程》第 18.8.e 款要求 ICANN 董事会任命一名 ICANN 员工担任联络人,以促进审核小组和 ICANN 之间的正式沟通。

      鉴于《ICANN 章程》第 18.3 款规定了审核小组的范围和职责。

      鉴于《ICANN 章程》第 18.3.j 款要求审核小组“确定在根据 IANA 域名职能合同和 IANA 域名职能 SOW 履行 IANA 域名职能,以及 CSC 和 EC 在履行与 PTI 监管相关的职能方面的待改进流程或其他方面”。

      鉴于《ICANN 章程》第 18.11 款要求 ICANN 组织为审核小组履行职责提供必要的管理和运营支持,包括为所有会议提供和促进远程参与。

      兹此发布第 2018.09.16.03 号决议:董事会特此开展首轮 IANA 域名职能审核,并指示 ICANN 总裁兼首席执行官或其指定人员为审核小组履行职责提供必要的管理和运营支持,包括为所有会议提供和促进远程参与。

      第 2018.09.16.04 号决议:董事会要求其余任命组织完成其任命成员和联络人的流程。此外,任命组织应进行协调,以确保组建的审核小组符合《ICANN 章程》第 18.8.c 款中的多样性要求。

      第 2018.09.16.05 号决议:应根据《ICANN 章程》第 18.3 款中规定的范围开展 IFR。

      第 2018.09.16.06 号决议:为履行董事会任命一名 ICANN 组织员工担任联络人以促进审核小组与 ICANN 组织之间的正式沟通的义务,董事会指示 ICANN 总裁兼首席执行官指定适当的成员来担任这一角色。

      第 2018.09.16.03 – 2018.09.16.06 号决议的理由

      董事会正在开展首轮定期 IANA 域名职能审核(“IFR”)以满足《ICANN 章程》第 18.2 款的要求,即开展首轮定期 IFR 的时间不得迟于 2018 年 10 月 1 日。IFR 是作为 IANA 管理权移交的一部分而制定的新问责机制,用于通过遵守 IANA 域名职能合同和 IANA 域名职能工作声明 [PDF, 626 KB] 中规定的合规要求,确保 PTI 符合其域名客户的需求和期望。

      任命组织已经采取措施,为审核小组任命成员和联络人。董事会要求其余任命组织完成其任命成员和联络人的流程,以便组建的审核小组能够开始开展工作。为了确保审核小组的最终组成符合《ICANN 章程》的要求,董事会要求任命组织进行协调,以根据《ICANN 章程》第 18.8.c 款最终敲定审核小组的组成。ICANN 组织已接受指示,提供一名员工作为联络人,为审核小组与 ICANN 组织之间的沟通提供支持。

      董事会了解,《ICANN 章程》第 18.3 款对 IFR 的范围进行了明确的定义。这可能与《章程》第 17.3 款规定的正在进行的 CSC 效率审核存在一定的重叠,该规定指出:“应在首次 CSC 会议之后两年对 CSC 的效率进行审核…审核方法将由 ccNSO 和 GNSO 确定”。CSC 效率审核必须在 2018 年 10 月 6 日之前开始,这一天距离客户常任委员会召开其首次会议起刚好两年。潜在的重叠是指与 IFR 审核小组职责范围内的事项发生重叠,以“确定 CSC…在履行…与 PTI 监督有关的职能方面有待改进的流程或其他方面”。为确保对社群资源的有效和高效使用,董事会鼓励 IFR 审核小组在其工作中考虑任何未来的发现、建议或 GNSO 和 ccNSO 采用的与客户常任委员会的效率审核有关的方法和标准。

      董事会批准的 2019 财年 ICANN 年度运营规划和预算包含了为 IFR 提供支持的预算资源。

      此行动符合 ICANN 的使命,因为它支持 ICANN 履行其与协调根区域名的分配与指定相关的使命,并且这也是对公共利益的直接支持。ICANN 董事会正在根据《ICANN 章程》的要求采取行动。因此,无需通过公共评议期来告知董事会的行动。

    4. .coop TLD 注册管理机构协议续约

      鉴于 .coop 注册管理运行机构 DotCooperation LLC 与 ICANN 组织签订有现有协议,且该协议定于 2018 年 11 月 22 日到期。

      鉴于 ICANN 组织与注册管理运行机构进行了协商,制定了续约协议提案并于 2018 年 6 月 11 日至 2018 年 7 月 27 日针对 .coop TLD 征求了公众意见,收到了两个组织提供的意见。已向董事会提交意见摘要和分析。

      鉴于董事会在审核和考虑了这些意见后决定,无需对 .coop 续约注册管理机构协议提案进行修订。

      鉴于 .coop 续约注册管理机构协议包括与新 gTLD 注册管理机构协议的同等规定一致的新条款。

      兹此发布第 2018.09.16.07 号决议:批准 .coop 续约注册管理机构协议提案,并授权总裁兼 CEO 或其指定人员采取适当行动来最终确定并签署该协议。

      第 2018.09.16.07 号决议的理由

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

      ICANN 组织和 DotCooperation LLC 于 2007 年 7 月 1 日签署了关于 .coop 顶级域运营的注册管理机构协议。当前的 .coop TLD 注册管理机构协议于 2018 年 11 月 22 日到期,注册管理运行机构有权根据现有协议进行推定续约。续约注册管理机构协议提案已发布以征询公众意见,公共评议期为 2018 年 6 月 11 日至 2018 年 7 月 27 日。现在,董事会决定批准 .coop 续约注册管理机构协议提案,以便由 DotCooperation LLC 继续运营 .coop TLD。

      正在考虑的提案是什么?

      .coop TLD 续约注册管理机构协议提案基于当前的.coop TLD 注册管理机构协议,其修改已得到 ICANN 组织和 DotCooperation LLC 同意,并包括来自新 gTLD 注册管理机构基本协议中的某些规定。

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

      ICANN 组织就 .coop 续约注册管理机构协议提案征询了公众意见,公共评议期为 2018 年 6 月 11 日至 2018 年 7 月 27 日。此外,ICANN 组织与注册管理运行机构进行了协商,旨在商定待纳入 .coop 续约注册管理机构协议提案(已发布以征询公众意见)中的条款。

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

      有关 .coop 续约注册管理机构协议提案的公众意见论坛于 2018 年 7 月 27 日关闭,ICANN 组织收到了两 (2) 条意见。这些意见可归纳在下文列出的两个类别中。

      1. 在传统 gTLD 注册管理机构协议续约中纳入新 gTLD 权利保护机制 (RPM) 和保护措施(例如公共利益承诺):有一位评论者表示支持在续约协议提案中纳入某些权利保护机制(如统一快速中止程序和商标授权后争议解决程序)和新 gTLD 注册管理机构协议中包含的公共利益承诺(即保护措施)。相反,有一位评论者对于在传统协议中纳入基本 gTLD 权利保护机制表示担忧。他们认为,不应通过合同协商来增加这些条款,而应通过 GNSO 政策制定流程(“PDP”)解决此问题。
      2. .coop TLD 续约注册管理机构协议提案和传统 gTLD 注册管理机构协议协商的通用协商流程:有一位评论者表示,使其感到鼓舞的是,.coop 正在从基本 gTLD 注册管理机构协议过渡到技术和运营规范,但感到失望的是 .COM 和 .NET 尚未对其条款实施此项过渡。另一位评论者重申了对协商流程的反对意见,指出 GDD 员工“单方面确定了注册管理机构协议的新现状”并通过超越其“权力和推翻旨在保护多利益相关方社群的透明度和包容性的保护措施”,“用其 (GDD) 判断取代 GNSO 政策制定”。

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

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

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

      董事会仔细考虑了收到的关于 .coop 续约注册管理机构协议的公众意见以及这些意见的总结和分析。董事会还在与 ICANN 组织的双边协商中讨论了注册管理运行机构达成一致的条款。

      虽然董事会承认某些社群成员表达了关于在续约注册管理机构协议提案中纳入 URS 的担忧,但董事会指出,在续约注册管理机构协议提案中纳入 URS 是基于 ICANN 组织与注册管理运行机构的协商,注册管理运行机构在协商中表达了其有意根据新 gTLD 注册管理机构协议续约其协议。

      董事会指出,实施建议团队 (IRT) 建议将 URS 作为所有新 gTLD 的强制性权利保护机制 (RPM)。董事会要求 GNSO 就建议的某些权利保护机制(其中包括 URS)是否符合 GNSO 关于引入新 gTLD 的拟议政策提出意见,以及就该等权利保护机制是否能恰当、有效地实现 GNSO 所述原则和目标提出意见。商标问题专项审核小组 (STI) 考虑了此事项并得出结论,确定“URS 应作为所有新 gTLD 的一项必需的 RPM”。也就是说,GNSO 认为 URS 与它的任何现有政策建议不存在不一致的情况。

      虽然 URS 是通过上述流程(包括 GNSO 公开审核和讨论)制定并完善的,但此程序尚未被采纳为共识性政策,ICANN 无法使其成为任何 gTLD(2012 年新的 gTLD 轮次中的新 gTLD 申请人除外)的强制性程序。

      因此,董事会批准续约注册管理机构协议不会使 URS 成为任何传统 TLD 的强制性程序,而且,这样做也是不恰当的。就 .coop 而言,纳入 URS 是作为注册管理运行机构与 ICANN 组织协商的提案的一部分而制定的。

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

      董事会批准 .coop 续约注册管理机构协议对技术和运营产生了积极的影响。例如,.coop 续约注册管理机构协议包括与基本 gTLD 注册管理机构协议相同的已批准服务,以及 DNS 服务 — TLD 区域内容和活动域目录。此外,DotCooperation LLC 还将按照要求针对 .coop 遵循与基本 gTLD 注册管理机构协议相同的公共利益承诺。采取此行动有助于 ICANN 组织履行对加强 DNS 安全、稳定与弹性作出的承诺,因此是符合公共利益的。

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

      预计 .coop 续约注册管理机构协议不会产生重大的财务影响。

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

      .coop 续约注册管理机构协议预计不会造成任何与 DNS 相关的安全、稳定或弹性问题。实际上,.NET 续约注册管理机构协议包括了便于在出现某些与 DNS 安全性或稳定性有关的威胁时更快采取行动的条款,并且具有其他技术优势,可确保所有注册管理机构服务的一致性,为最终用户提供更可预测的环境。

    5. 任命 2019 年提名委员会主席和候任主席

      鉴于董事会治理委员会 (BGC) 审核了 2019 年度提名委员会 (NomCom) 主席和候任主席的意向书,考量了 2018 年度 NomCom 领导人的同行评审结果,并与候选人进行了面谈。

      鉴于 BGC 建议任命 J.·戴蒙·阿什克拉夫 (J. Damon Ashcraft) 为 2019 年度 NomCom 主席,雪莉·安·米勒 (Cheryl Ann Miller) 为 2019 年度 NomCom 候任主席。

      兹此发布第 2018.09.16.08 号决议:董事会在此任命 J.·戴蒙·阿什克拉夫为 2019 年度提名委员会主席,任命雪莉·安·米勒为 2019 年度提名委员会候任主席。

      第 2018.09.16.08 号决议的理由

      《ICANN 章程》要求董事会任命提名委员会 (NomCom) 主席和候任主席。请参见《ICANN 章程》第 8 条第 8.1 款。董事会已授权董事会治理委员会 (BGC) 承担推荐 NomCom 主席和候任主席供董事会批准的责任。(参见《BGC 章程》:http://www.icann.org/en/committees/board-governance/charter.htm)。2018 年 6 月 13 日,BGC 发布了征求意向书 (EOI) 的公告,要求在 2018 年 7 月 2 日前提交意向书(参见 https://www.icann.org/news/announcement-2-2018-06-13-en)。BGC 收到并审核了多份意向书,查看了 2018 年度 NomCom 领导层的同行评审结果,并在提出建议前与候选人进行了面谈。董事会已考量并同意 BGC 推荐的 2019 年度 NomCom 主席和 2019 年度 NomCom 侯任主席。董事会还想感谢所有有意成为 2019 年度 NomCom 领导人并提交了意向书的人士。

      通过公开 EOI 流程选拔和任命 NomCom 主席和侯任主席(包括审核候选人)符合公共利益,因为这对 ICANN 的透明度和问责制产生了积极影响。这也完全符合 ICANN 的使命。

      采纳 BGC 的建议不会对 ICANN 产生额外的财务影响,并且不会对域名系统的安全、稳定与弹性产生负面影响。

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

  2. 主要议程:

    1. GAC 建议:巴拿马公报(2018 年 6 月)

      鉴于政府咨询委员会 (GAC) 在 ICANN 第 62 届巴拿马城会议期间举行了会议,并在 2018 年 6 月 28 日的公报 [PDF, 576 KB](“巴拿马公报”)中公布了向 ICANN 董事会提出的建议。

      鉴于巴拿马公报是董事会与 GAC 于 2018 年 7 月 31 日进行的沟通的主题。

      鉴于在 2018 年 7 月 27 日的信函 [PDF, 160 KB] 中,GNSO 理事会就巴拿马公报中与通用顶级域名相关的建议向董事会提供了反馈,便于董事会及社群了解可能与 GAC 建议相关的 gTLD 政策活动。

      鉴于董事会在考虑了其与 GAC 之间的沟通以及 GNSO 理事会提供的信息之后,制定了一张计分卡,用于回应 GAC 在巴拿马公报中的建议。

      兹此发布第 2018.09.16.09 号决议:董事会采纳题为“GAC 建议 – 巴拿马公报:行动和更新(2018 年 9 月 16 日)”[PDF, 294 KB] 的计分卡,以回应巴拿马公报 GAC 建议中的事项。

      第 2018.09.16.09 号决议的理由

      根据《ICANN 章程》第 12 条第 12.2(a)(ix) 款,GAC 可以“直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议”。在巴拿马公报(2018 年 6 月 28 日)中,GAC 公布了向董事会提出的有关以下事项的建议:《通用数据保护条例》(GDPR) 和 WHOIS,保护 gTLD 中国际政府间组织 (IGO) 的名称和缩写,以及二级双字符国家代码。GAC 还针对 GAC 圣胡安公报中有关 GDPR 和 WHOIS 的推迟事项的先前建议提供了跟进建议。《ICANN 章程》要求董事会在制定和采纳政策时考虑 GAC 对公共政策问题的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。对于 GAC 完全达成共识(按照章程规定)的任何 GAC 建议,只有不少于 60% 的董事会成员投反对票后才可予以否决。然后,GAC 和董事会必须尝试真诚、及时、高效地寻找双方都可以接受的解决方案。

      董事会今天将采取行动,接受与 GDPR 和 WHOIS 以及保护 IGO 有关的所有事项,并将推迟考虑与二级双字符国家代码有关的两 (2) 个建议事项,等待与 GAC 进行进一步讨论。董事会将在进行这些讨论之后,确定是否需要采取进一步行动。如需了解董事会的行动,请参见 2018 年 9 月 16 日计分卡 [PDF, 294 KB]。

      在采纳对巴拿马公报中 GAC 建议的回应时,董事会审核了诸多材料,包括但不限于以下材料和文件:

      计分卡中对 GAC 建议的采用有助于解决 GAC 关于 gTLD 和其他事项的建议,将对社群产生积极影响。通过此项决议不会产生任何可预见的财务影响。批准此项决议不会产生任何与 DNS 相关的安全、稳定或弹性问题。董事会对 GAC 建议的考量符合公共利益,认可了 GAC 在就公共政策事项提供建议方面发挥的作用,并且符合 ICANN 的使命。

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

    2. 根服务器战略

      鉴于 ICANN 当前部署大量单个服务器(“L 单节点”)和少量大型多服务器安装(“L 集群”)的方法截至目前已成为防范根服务器系统攻击的充分防御措施。

      鉴于技术社群中许多人认为,当前部署的根服务器系统存在无法跟上攻击能力的增长步伐的风险,因此,根服务器系统会越来越容易遭受攻击流量(无论是恶意实体发起的还是因错误配置、误用或漏洞而造成的)。

      鉴于对根服务器系统的成功攻击会对 DNS 的安全性和稳定性造成严重风险,并对作为协调 DNS 根服务器系统的运作和演进的协调者的 ICANN 组织带来潜在的存在风险。

      鉴于旨在减少攻击对根服务器系统影响的综合性战略应考虑多种方法,这些方法利用和增强根服务器运营商的现有做法,整合新技术进展和方法,并增强对整个系统的观察和监督。

      兹此发布第 2018.09.16.10 号决议:董事会指示 ICANN 组织(作为 ICANN 管理的根服务器/L 根 [IMRS] 的运营商)与社群合作以最终确定减少攻击对 IMRS 的影响的战略,并在最终确定后指示总裁兼首席执行官将开始实施该战略,制定出包括相关时间表和潜在支出项目的计划,以便进行后续的董事会审核和批准。

      第 2018.09.16.10 号决议的理由

      从架构上讲,DNS 域名空间的根被用作单点,对域名空间中任何域名的查询都必须至少通过该点传递一次。这给整个 DNS 带来了“单点故障”风险。截至目前,这项风险已通过“强化”为根提供域名服务的基础设施得到了缓和。这种强化历来通过扩展容量来实施,通过增加域名服务器的带宽或使用“Anycast”路由,部署更多域名服务器来回答世界各地关于根的问题。

      但是,由于互联网技术和设施的持续演进,特别是全球各地“物联网”设备的部署和网络容量的增加,再加上这些设备和网络缺乏充分的安全性,攻击者越来越能够削弱互联网基础设施。具体而言,攻击能力的增长可能超过根服务器运营商社群扩展防御能力的能力。虽然近期仍有必要继续扩展防御能力,但是传统方法的长期前景看似暗淡无光。

      此外,由于缺乏重要的 DNSSEC 验证部署,根服务器系统的响应仍有可能遭受完整性攻击。同样,由于假定 DNS 消息以未加密的方式发送,因此根服务器系统(即解析器)的用户可能受到机密性攻击。虽然这些攻击不一定是新的,但是对 DNS 的依赖却在不断增加,从而对根服务器系统的依赖也在增加,这表明需要提出一项新战略,以减少这些攻击对根服务器系统的影响。

      为满足这项要求,ICANN 组织为 ICANN 管理的根服务器制定了一项综合性战略,除了扩展现有的传统保护机制外,还力求充分利用商业云基础设施,进一步分散根服务,鼓励部署 DNSSEC 验证,促进开发 DNS 的隐私增强功能,加强与根服务器运营商社群以及解析器运营商的互动,并增强根系统监控。

      这项战略应在与社群(特别是 RSSAC)合作的基础上最终确定。一旦最终确定,在战略实施方面应首先制定详细的项目计划,其中包括时间表、里程碑以及预计支出。完成项目计划后,应将计划提交至董事会供其审核和批准。

      最终确定根战略和制定必要的详细项目计划的决议预计需要人力资源,这已纳入了 2019 财年预算中,因此预计不会产生额外预算影响。

      此决议符合公共利益和 ICANN 的使命,因为它支持 ICANN 组织在确保互联网唯一标识符系统的稳定和安全运营方面开展的工作。

    3. 继续进行 KSK 轮转

      鉴于 ICANN 组织在“根区 KSK 运营商 DNSSEC 实践声明”中承诺,“运营 5 年之后”对 KSK 进行轮转。

      鉴于 ICANN 组织组建了一个设计团队,以制定全套计划来实施 KSK 轮转。

      鉴于作为计划实施的一部分,ICANN 组织收集了某些数据,这些数据引发了与 KSK 轮转对最终用户的影响有关的问题。

      鉴于 ICANN 组织于 2017 年 9 月 27 日暂停了轮转以了解所收集的数据。

      鉴于 ICANN 组织在与 DNS 技术社群成员协商后进一步了解了所收集的数据。

      鉴于 ICANN 组织推断了 KSK 轮转的影响。

      鉴于 ICANN 组织已更新了全部计划文件,并创建了“继续进行根 KSK 轮转的更新计划”。

      鉴于董事会已收到 RSSAC、RZERC 和 SSAC 关于计划文件的意见,且这些意见表明这些组织认为没有理由不继续根据更新的计划进行 KSK 轮转,且部分社群成员(特别是 DNS 技术社群中的成员)表达了对进一步推迟 KSK 轮转造成的影响的担忧,特别是:不继续推进 KSK 轮转不符合社群期望的共识;不受迄今获得的数据支持;可能使社群对 ICANN 组织的 DNSSEC 消息传递产生混淆或丧失社群对此的关注;可能促成这样一种看法,即 KSK 永远不会轮转,从而可能导致当前 KSK 陷入难以改变的系统;降低 DNSSEC 作为值得信赖的系统的可信度。

      鉴于受 KSK 轮转负面影响的预计最终用户数明显低于社群规定的门槛值(即最终用户的 0.5%),并且对于受影响的人而言,这种负面影响的识别和补救应该都是直截了当的。

      鉴于 ICANN 认为继续及时进行轮转对社群带来的利益大于难以量化的风险。

      兹此发布第 2018.09.16.11 号决议:董事会指示 ICANN 组织继续根据“继续进行根 KSK 轮转的更新计划”进行 KSK 轮转。

      第 2018.09.16.11 号决议的理由

      由于意外数据(特别是从 RFC 8145 的早期实施而收到的数据),DNS 根 KSK 轮转计划于 2017 年 9 月 27 日暂停,由此产生了验证解析器在多大程度上为预定于 2017 年 10 月 11 日实施的轮转做好准备的质疑。ICANN 组织以及其他组织一起分析了数据,确定有迹象表明相对较小比例的解析器可能受到 KSK 轮转的负面影响,但是他们也证实,收到的数据不适合用于确定将受影响的最终用户数量。

      根据这项研究,ICANN 组织要求技术社群就行动计划提出建议。虽然存在少数人的异议,但该社群的大多数意见是 ICANN 组织应以有序的方式继续推行 KSK 轮转程序。

      根据这项建议,ICANN 组织制定了一份名为“继续进行根 KSK 轮转的计划”的摘要计划,以于 2018 年 10 月 11 日开展根 KSK 轮转。ICANN 组织于 2018 年 2 月 1 日发布了摘要计划供社群审核(参见 <https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>)。意见征询时间超出了通常的 45 天期限,以便于在 ICANN 第 61 届圣胡安会议和伦敦 IETF 101 上介绍该计划,并在这些论坛期间征集更多社群意见。

      2018 年 4 月 2 日之前收到的社群回复一致地支持已发布的计划,一些建议指出应该开展更多外展,ICANN 组织已经这样做了。根据社群回复,ICANN 组织制定了“继续进行根 KSK 轮转的更新计划”,修改了最初的 KSK 轮转计划文件,以表明已经采取了哪些步骤、哪些步骤还需要根据修改后的日期采取。可以访问 <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>,查看这些计划文件。

      各个咨询委员会、利益相关方团体、组织和个人对拟议计划提出了社群意见。董事会请 RSSAC、RZERC 和 SSAC 针对拟议计划提出明确的意见。以下是对董事会的这项要求的回复:

      ICANN 组织考量了这三项来自咨询委员会的回复中的所有结果,特别是对于继续进行轮转表示迟疑的任何结果。总而言之,ICANN 组织认为这些结果表明,可能从未做好轮转准备的极少数互联网用户遭受服务中断的风险低于现在和将来定期进行 KSK 轮转的益处。随附的参考资料也列出了 ICANN 组织知晓的针对继续进行轮转的主要反对意见以及对这些反对意见的回复。

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

      此决议符合公共利益和 ICANN 的使命,因为它支持 ICANN 组织在确保互联网唯一标识符系统的稳定和安全运营方面开展的工作。

      这属于组织管理职能,除了已经请求提供的意见外,无需征询公众意见。

    4. 进一步考量 .AMAZON 申请

      鉴于 2012 年 Amazon EU S.à r.l.亚马逊公司申请了 .AMAZON 和关于“Amazon”这一词语的两个国际化域名 (IDN) 版本(下称“.AMAZON 申请”)。.AMAZON 申请是巴西和秘鲁政府(在玻利维亚、厄瓜多尔、圭亚那的支持下)提交的政府咨询委员会 (GAC) 早期预警的主题,通过早期预警通知亚马逊公司这些政府制定了关于其所申请的字符串的公共政策。

      鉴于 2013 年 7 月,在德班公报中,.AMAZON 申请是 GAC 共识性建议的主题,该共识性建议指出不应继续处理 .AMAZON 申请。2014 年 5 月 14 日,新 gTLD 项目委员会接受该建议并指示 ICANN 组织不继续处理 .Amazon 申请。

      鉴于 2015 年 10 月,亚马逊公司向亚马逊合作条约组织 (ACTO) 成员国提交了一份提案,试图达成对双方皆有益的解决方案。这项提案遭到了拒绝。

      鉴于 2017 年 7 月,亚马逊公司在 2016 年提交的独立审核流程 (IRP) 中胜诉。鉴于 IRP 声明中建议董事会“立即重新评估亚马逊的申请”并“进行客观独立的判断,确定是否存在有根据且基于绩效的公共政策理由来拒绝亚马逊的申请”。

      鉴于 2017 年 10 月 29 日,董事会请 GAC 提供关于 GAC 就 .AMAZON 申请提出的建议的更多信息。在其 2017 年 11 月阿布扎比公报中,GAC 建议董事会“继续促进亚马逊合作条约组织 (ACTO) 成员国与亚马逊公司之间的谈判,以期达成一个双方均可接受的解决方案,允许使用 .amazon 作为顶级域名。”

      鉴于 2018 年 2 月 4 日,ICANN 董事会接受 GAC 建议,并要求 ICANN 组织总裁兼首席执行官“促进亚马逊合作条约组织 (ACTO) 成员国与亚马逊公司之间的谈判”。

      鉴于亚马逊公司于 2017 年 10 月向 GAC 和 ACTO 提交了新提案。亚马逊公司于 2018 年 2 月提交了进一步更新的提案后,ACTO 成员国于 2018 年 9 月 5 日发布了声明,指出“…亚马逊国家得出结论称,提案不能构成保护其与‘.amazon’ TLD 授权有关的固有权利的充分依据”。ACTO 成员国还指出,.AMAZON 授权“需要亚马逊国家的同意”并且他们“有权参与‘.amazon’ TLD 的治理”。

      鉴于 ACTO 成员国于 2017 年 10 月确认,“…在任何语言中,亚马逊的名称都是亚马逊国家的文化遗产和身份的一部分,除非亚马逊国家另有约定,否则应保留其不被用作一级域名,以促进亚马逊人民的利益和权利并帮助其融入信息社会”。

      鉴于董事会对 ACTO 成员国在维护亚马逊地区的公共利益方面所做工作(包括推广和保护亚马逊地区的自然和文化遗产)表示了解和赞赏。

      兹此发布第 2018.09.16.12 号决议:ICANN 总裁兼首席执行官根据指示支持为授权 .AMAZON 申请中代表的字符串制定解决方案,包括向 ACTO 成员国分享对这些顶级域的使用情况,以支持亚马逊地区国家的文化遗产。

      第 2018.09.16.13 号决议:董事会指示 ICANN 总裁兼首席执行官或其指定人员(如可能)向董事会提供关于 .AMAZON 申请的提案,便于董事会针对 .AMAZON 申请中代表的字符串的授权做出决定。

      第 2018.09.16.14 号决议:ICANN 总裁兼首席执行官或其指定人员根据指示向董事会提供关于 .AMAZON 申请的状态的定期详细更新。

      第 2018.09.16.12 – 2018.09.16.14 号决议的理由

      此行动支持 ICANN 董事会考量亚马逊国家提交的独立审核流程 (IRP) 的结果,以及考量政府咨询委员会提出的与 .AMAZON 申请有关的建议。董事会今天正采取此行动,以提高授权 IRP 小组声明中所述的 .AMAZON 申请的可能性,同时承认通过 GAC 建议提出的关于这些申请的公共政策问题。

      董事会今天采取此行动的目的是支持进一步工作,以便制定允许推进 .AMAZON 申请的解决方案,并使这种推进与 GAC 关于这个主题的建议和意见保持一致。

      背景

      亚马逊公司申请了 .AMAZON 和关于“Amazon”这一词语的两个国际化域名 (IDN) 版本(下称“.AMAZON 申请”)。为回应 .AMAZON 申请,巴西和秘鲁政府(在玻利维亚、厄瓜多尔和圭亚那的支持下)根据《申请人指导手册》通过 GAC 提交了早期预警,相关政府在其中表示:“若向私营公司授予这一特殊 gTLD 的专有权,则将无法将此域名用于实现与保护、推广亚马逊生物群落以及与提高人们对相关问题认识有关的公共利益。同时还会阻碍利用此域名将与该地区居民相关的网页集中起来。”(早期预警,参见 https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB]。)

      在北京公报(2013 年 4 月)中表示 .Amazon 申请需要 GAC 进一步考量后,GAC 在德班公报(2013 年 7 月 18 日)中向 ICANN 董事会提出共识性建议(下称“GAC 建议”),认为不应继续处理 Amazon 申请 (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon)。

      2014 年 5 月 14 日,董事会(通过 NGPC)接受 GAC 建议并指示 ICANN 不继续处理 Amazon 申请。(第 2014.05.14.NG03 号决议,参见 https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b)。

      2015 年 10 月,亚马逊公司向亚马逊合作条约组织 (ACTO) 成员国提交了一份提案,试图达成对双方皆有益的解决方案。但是,该提案被 ACTO 成员国拒绝。随后,亚马逊公司于 2016 年 3 月开始进行独立审核流程 (IRP)。IRP 于 2017 年 7 月结束,IRP 小组得出的结果对亚马逊公司有利。ICANN 董事会在遵循 IRP 结果和更多 GAC 建议的基础上,让 ICANN 组织支持亚马逊公司和 ACTO 成员国通过谈判达成解决方案。

      2017 年 10 月,在 ICANN 第 60 届阿布扎比会议期间,亚马逊公司向 GAC 和 ACTO 成员国提交了一项新的“实际妥协”提案。2018 年 2 月,在 ICANN 组织促进的进一步谈判的基础上,亚马逊公司提交了进一步更新的提案。2018 年 9 月 5 日,ACTO 工作组审核提案后,在亚马逊合作委员会会议上,ACTO 成员国发布了一项声明,指出“…亚马逊国家得出结论称,提案不能构成保护其与‘.amazon’ TLD 授权有关的固有权利的充分依据”。

      亚马逊公司提案

      自 2015 年 10 月以来,亚马逊公司已向 ACTO 成员国提交了各种提案,以期达成双方均认可的解决方案。最初的 2015 年 10 月提案被 ACTO 成员国拒绝,导致亚马逊公司最终提交了 IRP。在 IRP 提出解决方案后(IRP 小组得出的结果对亚马逊公司有利),在 ICANN 第 60 届阿布扎比会议上,亚马逊公司向 GAC 提交了一项新的“实际妥协”提案。2018 年 2 月,亚马逊公司与 ACTO 成员国在 ICANN 组织的促进下进行谈判之后,亚马逊公司提交了进一步更新的提案。根据此提案,亚马逊公司提出了四个主要行动方案:

      1. 通过如下方式,帮助提高亚马逊地区及其人民在全球的知晓度并保护他们的文化遗产:
        1. 建立双方认同的二级域,以便于提高亚马逊地区的知晓度。在四年期限内,亚马逊公司将承担高达 1,000,000 美元的网站费用;
      2. 通过如下方式,帮助预防滥用与亚马逊地区及其人民有关的域名:
        1. 同意保留采用英语、西班牙语和葡萄牙语的大量二级域名;
      3. 组建指导委员会来监督协议的实施。
      4. 开展商誉工作,在使用亚马逊公司服务和产品方面向 ACTO 成员国提供高达 5,000,000 美元的信用额度。

      此外,亚马逊公司提议帮助 ACTO 成员国创建信息项目,以帮助宣传协议带来的利益。

      ACTO 对亚马逊提案的顾虑和回复

      ACTO 成员国对使用 .AMAZON TLD 的顾虑主要涉及亚马逊地区的国家和个人为公共利益目的使用域名的能力。在巴西和秘鲁于 2012 年 11 月发布的早期预警中,这两个国家声明:

      “若向私营公司授予这一特殊 gTLD 的专有权,则将无法将此域名用于实现与保护、推广亚马逊生物群落以及与提高人们对相关问题认识有关的公共利益。同时还会阻碍利用此域名将与该地区居民相关的网页集中起来。”

      2017 年 10 月,在 IRP 小组发表关于 .AMAZON 的最终声明后,ACTO 成员国发布了一项声明,重申:

      “…在任何语言中,亚马逊的名称都是亚马逊国家的文化遗产和身份的一部分,除非亚马逊国家另有约定,否则应保留其不被用作一级域名,以促进亚马逊人民的利益和权利并帮助其融入信息社会”。

      最后,在亚马逊公司于 2018 年 2 月提交了更新提案之后(包括 ACTO 成员国在寻求有关理解该提案的澄清之后),ACTO 成员国于 2018 年 9 月 5 日向董事会发送了一封信函,指出这“需要亚马逊国家的同意”并且他们“有权参与‘.amazon’ TLD 的治理”。此外,ACTO 成员国声明,“提案不能构成保护其与‘.amazon’ TLD 授权有关的固有权利的充分依据”。

      但是,成员国提到,他们愿意“与 ICANN 董事会合作…以期维护他们作为主权国家的权利”。

      董事会考量的事项

      采取该行动时,董事会考量了:

      • 亚马逊国家于 2015 年 10 月 6 日和 2018 年 2 月 7 日提出的提案;
      • .AMAZON 独立审核流程中的 IRP 小组声明;
      • 亚马逊公司于 2017 年 10 月提交给 GAC 和 ACTO 成员国的提案;
      • NGPC 于 2014 年 5 月 14 日针对 .AMAZON 申请采取的行动,以及董事会于 2017 年 10 月 29 日和 2018 年 2 月 4 日针对 .AMAZON 申请采取的行动;
      • ACTO 于 2018 年 9 月 5 日发送的信函及相关附录。

      影响

      此行动预计会对 ICANN 组织产生较小的资源影响,具体视满足董事会的指示所需的资源而定。但是,对于解决与授权 .AMAZON 申请相关的持续僵局产生的潜在影响而言,使用资源来找到适合的解决方案是首选做法。此行动符合 ICANN 的使命,因为这促进了新 gTLD 项目的开展以及 DNS 的预期扩展。此行动也符合公共利益,因为它平衡了增加 DNS 竞争力的核心价值,并同时承认政府对公共政策建议的提供。

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

    5. 其他事务

      未达成任何决议。

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