Skip to main content
Resources

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

本页面还提供其他语种:

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

  1. 主要议程:
    1. 注册目录服务审核 (RDS-WHOIS2) 最终报告及建议
  1. 主要议程:

    1. 注册目录服务审核 (RDS-WHOIS2) 最终报告及建议

      鉴于《ICANN 章程》第 4.6 款规定,ICANN 有义务进行“定期审核,评估当时最新的 gTLD 注册管理机构目录服务的效果及其实施是否符合法律实施的合法需求,促进消费者信任并保护注册人数据(‘目录服务审核’)。”为完成这项任务,一个由社群领导的审核小组 — 注册目录服务审核小组 (RDS-WHOIS2-RT) — 于 2017 年 6 月 2 日宣布成立。

      鉴于 2018 年 9 月 4 日,RDS-WHOIS2-RT 发布了报告草案启动公共评议

      鉴于 2019 年 9 月 3 日,RDS-WHOIS2-RT 向 ICANN 董事会提交了包含 22 项获得一致支持的建议的最终报告供其考量。

      鉴于 RDS-WHOIS2 最终报告代表了 11 名审核小组成员花了两年多时间、召开了超 1000 小时的会议并工作了无数个小时获得的最终成果。

      鉴于 2019 年 10 月 8 日,RDS-WHOIS2 最终报告和建议按章程要求公布并启动了公共评议,以便为董事会就报告采取行动提供参考。有关最终报告的社群意见摘要突出了多种观点。

      兹此发布第 2020.02.25.01 号决议:董事会对 RDS-WHOIS2-RT 成员在编制 RDS-WHOIS2 最终报告过程中的无私奉献精神和两年多来的工作表示感谢。

      第 2020.02.25.02 号决议:董事会对 RDS-WHOIS2-RT 最终报告中发布的 22 条建议的每一条采取行动,具体说明见题为“最终 RDS-WHOIS2 建议 — 2020 年 2 月 25 日董事会行动”的平衡记分卡。董事会指示 ICANN 总裁兼首席执行官或其指定人员采取在该平衡记分卡中指示 ICANN 组织 (ICANN org) 采取的所有行动。根据章程要求,对于每一条董事会不予批准的建议,董事会都在下方阐明了理由。

      第 2020.02.25.03 号决议:对于记分卡中指定为已批准的 15 条建议,董事会指示 ICANN 总裁兼首席执行官或其指定人员制定一份实施规划,并定期向董事会报告最新的进度。

      第 2020.02.25.04 号决议:对于处于未决状态的 4 条建议,董事会指示 ICANN 总裁兼首席执行官或其指定人员对正在进行的社群工作的成果完成一项影响评估,并确定了其依赖条件。董事会将结合影响分析来考虑未决建议,这一分析将在董事会就 gTLD 注册数据临时规范快速政策制定流程 (EPDP) 第 2 阶段建议采取行动后完成(如适当和适用)。董事会指示 ICANN 总裁兼首席执行官或其指定人员在解决所有依赖条件后尽快得出影响分析结果。董事会承诺定期将此议题包含在董事会议程中。

      第 2020.02.25.05 号决议:对于董事会转交通用名称支持组织理事会(GNSO 理事会)供其考量的两条建议(全部或部分),董事会指示 ICANN 总裁兼首席执行官或其指定人员相应地通知 GNSO 理事会。

      第 2020.02.25.06 号决议:董事会拒绝 R11.1 和 BY.1 两条建议。拒绝的理由分别在下文阐明。

      第 2020.02.25.01 – 2020.02.25.06 号决议的理由

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

      注册目录服务 (RDS) 审核是《ICANN 章程》第 4.6 款中规定的四项特定审核之一。特定审核由社群领导的审核小组负责开展,旨在评估 ICANN 在兑现其承诺方面的表现。审核对于维持有效的多利益相关方模型和帮助 ICANN 履行其《章程》第 1 条中详述的使命至关重要。审核机制也有助于确保 ICANN 服务于公共利益。

      而 RDS 审核工作则是 ICANN 承诺持续改进关键领域的重要组成部分。它最初出现在《义务确认书》(AoC) 中,并于 2016 年纳入《ICANN 章程》。RDS-WHOIS2 审核是第二次审核;第一次审核于 2012 年由 WHOIS 政策审核小组完成。1

      RDS-WHOIS2 审核小组 (RDS-WHOIS2-RT) 提出了 22 条最终建议供董事会考量,并于 2019 年 9 月 3 日发布了其最终报告2。董事会注意到,所有建议均是在达成全体一致共识后提交的,而且 RDS-WHOIS2 最终报告中还随附了一份 RDS 审核小组非商业利益相关方团体声明3,其中包含一些值得关注的方面。按照《ICANN 章程》第 4.6 款的要求,最终报告已发布进行公共评议,以便为董事会就最终建议采取行动提供参考。

      根据章程的要求,董事会有义务对其未予批准的每一条 RDS-WHOIS2 审核小组建议给出理由。为保持完整性,董事会在下方针对就每一条建议所采取的行动都给出了理由,不管建议被批准与否。

      正在考虑的提案是什么?

      RDS-WHOIS2-RT 正式成立于 2017 年 6 月,其最终报告代表了 11 名审核小组成员花了两年多时间、召开了超 1000 小时的会议并工作了无数个小时获得的最终成果4,报告评估了目录服务审核建议(WHOIS 政策审核小组)的实施程度,以及实施是否达到了预期的效果。审核小组还审查了当前 gTLD 注册管理机构目录服务的有效性,以及这项服务的推行是否能够满足执法工作的合理需求、促进消费者信任和保护注册人数据。此外,RDS-WHOIS2-RT 还对 ICANN 合同合规职能进行了评价,“旨在:(a) 评估 ICANN 通过 ICANN 合同合规行动、结构和流程执行与 RDS (WHOIS) 相关的现有政策时的效率与透明度,包括执行行动的一致性和相关数据的可用性;(b) 找出优先级较高的程序或数据缺口(如有);以及 (c) 就该小组认为可有效填补缺口的具体可衡量措施(如有)提出建议。”

      为完成执法需求分析,RDS-WHOIS2-RT 进行了一项调查5,旨在“针对 WHOIS 是否符合执法机构的合法需求收集证据,并评估在当前适应数据保护法的背景下变更产生的影响”。

      RDS-WHOIS2-RT 参考了 ICANN 组织的简报和可用文档,在整个审核周期与 ICANN 组织进行了交流,包括提交书面意见6供其考虑。

      董事会对 RDS-WHOIS2 在整个审核流程中的无私奉献和辛勤工作表示感谢。董事会感谢 RDS-WHOIS2-RT 在其职权范围内承认不断变化的 RDS 格局以及持续采取的举措,并指出考虑到 GDPR 的显著重要性,RDS-WHOIS2-RT 决定考虑 GDPR 可能对 RDS 产生的影响。

      在评估 RDS-WHOIS2 最终报告和建议时,负责此项工作的董事会决策委员会小组(RDS 董事会决策委员会小组)联系了 RDS-WHOIS2 实施指导人解释一系列问题,并确认了对其中一些建议的理解。实施指导人是多位审核小组成员,他们自愿就以下方面的问题做出必要的解释:建议的意图、理由、结论的事实依据、设想的时间线以及成功的实施措施7。自审核小组完成其工作以来,RDS 董事会决策委员会小组和 ICANN 组织就一直在和 RDS-WHOIS2 实施指导人进行沟通。此沟通的目的是明确特定建议的意图,为董事会考量最终建议提供参考。初步评估报告,包括请教 RDS-WHOIS2 实施指导人的问题在内,已经发布以作为讨论框架。8在本文的理由部分和平衡记分卡中,酌情参考了实施指导人给出的解释。

      就建议而言,董事会指出其在确定对每条建议采取的行动时考虑了一些广泛的领域和主题。

      建议的优先排序

      《ICANN 章程》(第 4.6 (a)(vii)(A) 款)规定“审核小组应尝试确定每项建议的优先顺序,并为此类优先排序提供理由。”在最终报告中,RDS-WHOIS2 表示其中有 11 条建议为“高优先级”,6 条为“中优先级”,5 条为“低优先级”,指出“经董事会审批并满足所有前提条件之后,应尽快实施所有标记为“高优先级”的建议。需要根据 ICANN 的总体工作重点考量中或低优先级的建议,但不得无限期延迟。”RDS-WHOIS2-RT 附上了对 22 条建议中每一条建议的优先排序理由。

      董事会指出,目前有超过 300 条建议出自特定审核,其中还不包括问责制和透明度第 3 轮审核 (ATRT3)、第二轮 DNS 安全、稳定和弹性审核小组 (SSR2)、组织审核和加强 ICANN 问责制跨社群工作组(CCWG-问责制)的第 2 工作阶段 (WS2) 的建议,这些建议要么董事会正在考虑,要么在等待董事会采取行动后予以实施;RDS-WHOIS2-RT 发布的 22 条建议包含在上述 300 条建议中。不管是章程还是运营标准,均未就这些建议的相关资源需求评价、跨所有审核小组的建议的优先排序,或者对优先建议的预算编制提供清晰一致的方法或依据。

      董事会已开始就优先排序问题与社群进行对话;详情请参见社群建议的资源分配和优先排序:社群讨论提案草案,在 2019 年 11 月的 ICANN66 公共会议“提高审核建议及其实施的效率”上也继续了该讨论。此外,ATRT3 确定建议的优先排序问题与其工作有关,对 ICANN 社群十分重要,因而在其报告草案中陈述了对此问题的观点供社群考虑。公共评议程序已于 2020 年 1 月 31 日结束,ATRT3 将考虑收到的意见来完善其报告,并准备于 2020 年 4 月发布最终报告。在对 ATRT3 的公共评议中,ICANN 董事会表示其支持提案中提出一个“对优先排序问题的总体建议”。董事会重申“审核建议的优先排序不能孤立地进行,优先排序流程必须加入到 ICANN 现有的预算和规划机制中。此外,ICANN 的所有部门都需要参与优先排序工作,包括 ICANN 社群、ICANN 董事会和 ICANN 组织。对社群提出的建议进行优先排序,需要结合所有 ICANN 工作的大背景,必须考虑对社群和 ICANN 组织资源及带宽的影响,考虑资源(包括资金)只需要预先准备,还是需要长期持续提供。”

      考虑到对大量建议进行优先排序是一项长期持续的工作,董事会认为社群的优先排序工作应当作为 RDS-WHOIS2-RT 在其对“高优先级”建议的定义中规定的“前提条件”来看待。参照对竞争、消费者信任和消费者选择审核小组 (CCT-RT) 建议的处理方式,董事会认为,对于不会显著增加成本和资源的实施工作,应当尽快开始。对于任何需要大量资源和预算的建议,都应纳入到运营规划和预算流程中,以便社群根据情况做出适当考量并排定计划工作的优先次序。

      董事会批准的建议

      董事会一共批准了 14 条建议,如平衡记分卡所载,分别为:R1.1、R1.2、R1.3、R3.1、R3.2、R10.2、R11.2、R12.1、R15.1、LE.1、LE.2、CC.1、CC.2 和 CC.3。这其中的每条建议均与 ICANN 的使命相一致,服务于公共利益并在董事会的职权范围内。

      董事会批准呼吁采用一个前瞻性机制来监督立法和政策发展的建议(R1.1 和 R1.2),并指出董事会已通过 2019 年 1 月的立法和监管跟踪计划的章程、董事会为 ICANN 总裁兼首席执行官设定的 2020 财年目标,以及通过董事会为其自身确定的工作优先级来更加全面地支持这项工作。主动监督世界各地的立法和政策发展对 RDS 的影响是一项运营任务,因而是 ICANN 组织的责任。RDS-WHOIS2 实施指导人解释,并且董事会同意,ICANN 组织的现有计划已经解决了这些关切,而且,通过 ICANN 组织各部门之间的持续协作,可以将必要的全球政策发展分析提供给董事会互联网治理工作组,该工作组定期接受 ICANN 组织的工作汇报并根据需要向 ICANN 董事会报告最新情况。此外,通过修订后的公开报告和简报,此信息可与 ICANN 社群全体成员分享。这与注册服务机构利益相关方团体 (RrSG) 提出、并在公共评议程序中得到非商业利益相关方团体 (NCSG) 支持的建议一致,即“此类更新也要向 GNSO 理事会提供,使其能够在必要时及时启动政策制定流程”。董事会注意到社群正在讨论如何改进既定机制和流程,其中政府咨询委员会 (GAC) 提到了 GNSO 理事会致 ICANN 组织的信函(2019 年 7 月 24 日),信中对现有工作提供了反馈。因此董事会采纳建议 R1.1 和 R1.2,并解释此项工作已在 ICANN 组织内进行。

      建议 R1.3 建议对董事会负责 RDS 活动的工作组提出一定的透明度要求,董事会注意到这项建议在公共评议程序中得到了普遍支持。董事会注意到,根据 RDS-WHOIS2 实施指导人给出的解释,建议并非要求制定一系列特定记录,而是寻求提供信息,说明正在开展的活动。考虑到 RDS-WHOIS2 实施指导人做出的解释,董事会批准 R1.3。

      在更新与 RDS (R3.1) 有关的公示信息方面,董事会指出 ICANN 组织已经启动一项工作,重写 WHOIS 门户网站的内容,改进网站导航。由于 RDS-WHOIS2-RT 建议让用户和焦点小组加入,预计完成期限可能会因此延长两到三个月。董事会注意到,这项建议在公共评议程序中得到了广泛支持。例如,一般会员咨询委员会 (ALAC) 指出该文档“对终端用户和注册人都很重要”。董事会采纳建议 R3.1。

      在与外展有关的建议 (R3.2) 上,董事会注意到公共评议程序中表达的关切。尽管 RrSG 同意,并且 NCSG 支持建议 R3.2,但 RrSG 指出要警惕成本和 ICANN 预算费用的增加。NCSG 质疑对此类外展的需求,并认为,“鉴于缺乏现成的数据”以及“有关任何 WHOIS 替代或 RDAP 实施”的不确定情况,RDS-WHOIS2 为该建议分配的优先级(高)是不恰当的。为解决公共评议期间表达的预算关切,董事会敦促 ICANN 组织在实施这条建议时要考虑在哪些地方可以提高效率,将与 RDS 有关的合作努力,和与注册数据访问协议 (RDAP) 有关的教育和认识进行匹配。董事会采纳建议 R3.2。

      建议 R10.2 和 R12.1 提出,推迟对 WHOIS1 政策审核小组关于隐私/代理以及国际化注册数据建议的有效性评估,并由未来的 RDS 审核小组进行评估。董事会批准这项建议,条件是本届审核小组同意向下一届 RDS 审核小组提出将这些项目纳入到其工作计划中。但是,董事会没有为 RDS 审核小组设立章程,因此不能就任何建议的处理做出指示。董事会提醒注意,RDS-WHOIS3-RT 可能不认为自己受到这些建议的约束。董事会注意到,建议 R10.2 和 R12.1 在公共评议程序中得到了广泛的支持,NCSG 除外。在 10.2 的语境下,NCSG 提醒,考虑到 gTLD 注册数据政策临时规范快速政策制定流程 (EPDP) 预期会发展出新系统,有很多建议将变得不再有意义。NCSG 建议可能有必要重新开始,并担心如果不这样做的话可能会“浪费财力”。董事会批准建议 R10.2 和 R12.1,同时也提醒,后续审核小组 (RDS-WHOIS3-RT) 可能不认为自己受到这些建议的约束。

      关于确保公共界面显示所有适用输出的建议 (R11.2),董事会指出,RDAP 的设计预期是未来需要更新或解决任何政策或合同变更。从可行性角度出发,董事会指出可能有必要开发 RDAP 查找工具,以发现域名在注册服务机构和注册管理机构数据上的差异。董事会观察到,这一建议在公共评议程序中得到了支持。例如,ALAC 指出“尽管 GDPR 减少了可公开的信息量,[…]仍要求维持完整的功能性”,而且“门户网站必须以清楚可用的方式提供所有可以获得的信息”。董事会批准建议 R11.2。

      建议 R15.1 就 RDS WHOIS2 建议的实施方法和跟踪提出了若干建议。董事会注意到,尽管项目管理方法、最佳实践和报告机制可以在短期内实施,但是,ICANN 组织实施工作的有效性可能要依据这些方法、最佳实践和报告机制产生的结果是否可以被社群认可为成功实施来进行评估。因此,要观察所建议方法的实施有效性,可能需要时间。此外,董事会确认该工作目前正在 ATRT3 内进行,属于简化对社群提出的建议进行审核和优先排序的范畴。这些工作的成果,将为如何实施这项建议提供参考。董事会注意到,尽管在公共评议程序中没有人提出异议,但注册管理机构利益相关方团体 (RySG) 提醒注意会给签约方造成的报告负担。董事会批准 R15.1,并指出 ATRT3 中关于简化审核和优先排序的建议可能会给本建议带来一定影响。

      在与执法机构有关的数据搜集项目上(LE.1 和 LE.2),董事会注意到这些建议不大可能及时完成,为 EPDP 的工作提供参考。董事会指示 ICANN 组织与 GNSO 理事会商量制定一个时间表,其中包含需要的调查数据类型(包括方法、最后期限和“其他用户”的含义)和目标受众,以及此类调查工作应何时完成以供未来的政策工作参考。董事会注意到公共评议程序中对此的支持,例如,ALAC 支持调查和信息搜集,并且认为审核小组在执法方面的发现“非常重要”。GAC 确认其支持利用调查和信息搜集,包括调查非执法机构的网络安全执业者,以帮助减轻所有形式的犯罪和对 DNS 的网络安全威胁。董事会也注意到意见中表达了一些担忧和异议,例如 NCSGRySGRrSG,包括对调查偏见、遵守合同以及 GDPR 背景下执法需求的不确定性等的担忧。尽管存在种种担忧,且尽管这一工作无法及时完成以促进 EPDP 第 2 阶段的工作,但董事会依然批准这些建议,因为它们与支持整个 ICANN 社群政策制定工作的努力相一致,并且可以融入到这些工作当中。

      建议 SG.1 提出,董事会应要求 ICANN 的合同包含对保护注册人数据的统一严格要求 (SG.1)。董事会注意到,在注册服务机构认证协议 (RAA) 中已经含有一些就特定安全违规通知 ICANN 的条款,而注册管理机构协议 (RA) 目前不要求注册管理运行机构在发生安全违规时通知 ICANN。正如 RDS-WHOIS2 RT 所考虑的,这些合同必须修改。但是,董事会不能通过接受来自 RDS-WHOIS2 RT 的建议,单方面地对签约方施加新义务。RA 和 RAA 的修改只能通过政策制定流程 (PDP) 进行,或者作为合同谈判的结果。不管是哪种方式,董事会均无法保证取得特定的成果。

      董事会注意到,RDS-WHOIS2 实施指导人解释 RDS-WHOIS2-RT 期望董事会通过 PDP 或通过指导合同谈判采取适当行动,包括他们的意见,他们不希望为响应某一条建议而启动特殊的合同谈判;而是可以在下一轮合同谈判时响应。

      在评估公共评议程序中收到的意见时,ICANN 董事会注意到 RySG 认为该建议体现在遵守数据保护法方面,应由 ICANN 组织和签约方直接处理。在 NCSG 的支持下,RrSG 对这些要求没有问题,“假设前提是任何合同更新都不会延伸到建议之外”,并且补充道“此类要求宜笼统不宜具体,只需提到诸如 GDPR 的最佳实践法规即可”。与此相对,企业选区 (BC) 认为数据外泄报告“对保护注册人数据至关重要”,并建议将此作为一个强制要求;知识产权选区 (IPC) 呼应了这一观点,认为追踪数据外泄的基本数据是进一步保护注册人数据的一个“简单但必要的步骤”。其他人提出了问题。

      董事会承认努力纳入此类规定可能是恰当的,但也提醒通知的范围需要与 ICANN 的使命和合同角色息息相关,例如要联系到破坏互联网 DNS 稳定、安全与弹性的威胁情况。因此在 ICANN 收到数据外泄通知,表明存在破坏互联网 DNS 稳定、安全与弹性的威胁情况的范围内,董事会批准 SG.1,并指示将此项建议纳入到与签约方的下一轮合同谈判中。董事会无法要求或保证任何谈判结果。

      RDS-WHOIS2-RT 的建议 CC.2 提出,ICANN 应采取行动确保所有 gTLD 域名注册目录条目均至少包含一组全面的注册人或管理联系人详细信息。对此董事会指出,EPDP 建议 29 提出,在删除任何管理联系人信息之前,注册服务机构必须确保它拥有注册域名持有人的联系人详细信息。但是,在 EPDP 第 1 阶段建议中要求收集和显示的注册域名持有人的联系人详细信息,与 2013 注册服务机构认证协议 (RAA) 中的要求并不相同。董事会也注意到,公共评议程序中出现了意见分歧:RrSG 不支持此建议并认为其“非常有问题”,NCSG 支持这一立场。此外,RySG 认为 CC.2“与社群已经制定或正在实施的政策存在明显重叠”。BC 讨论了对长期注册的矛盾要求。董事会注意到 RDS-WHOIS2 实施指导人对此的解释是,RDS-WHOIS 2 建议 CC.2 与 EPDP 第 1 阶段建议一致,并在后者的实施工作中处理。考虑到这一解释,加之 EPDP 工作已进入实施阶段,董事会批准建议 CC.2。

      董事会批准呼吁为 ICANN 合同合规部提供足够资源的建议 CC.3,并指出这已经纳入到 ICANN 组织现有的预算和规划流程之中。公共评议程序中没有记录到问题。例如,IPC 指出“为合规团队配备充足的人员和资源,满足其促进 ICANN 使命的完成这一重要职能依然非常重要”,并且 BC 也指出,“考虑到最近的变化和多名合规团队成员的离开,这条建议显得更加重要”。

      董事会置于“未决”状态的建议

      鉴于下述依赖条件,董事会将四条建议(R4.1、R4.2、R5.1 和 R10.1)置于未决状态。董事会承诺一旦所有与持续进行的社群工作相关的依赖条件和活动允许进行可行性和兼容性评估,将立即解决未决状态,对这四条建议采取恰当的行动。董事会期望通过 ICANN 定期进行的进度更新来监督这些建议方面的进展。

      对于 R4.1、R4.2、R5.1 和 R10.1,这些建议各自有其依赖条件,并与 EPDP 第 2 阶段第 2 批重点事务存在重叠。在董事会对 EPDP 的建议采取行动之前对这些建议采取行动,存在工作重复和重叠的风险。因此,董事会将所有这四条建议置于未决状态,直到董事会对 EPDP 第 2 阶段第 2 批重点事务采取行动之后再行解决。董事会确认 ICANN 组织对平衡记分卡中记录的这四条建议分别提供了信息供其考虑,但是董事会无意在此时考虑这些建议的内容。

      董事会移交给指定社群团体考量的建议

      董事会将建议 (CC.4) 移交给 GNSO 理事会。此建议呼吁 GNSO 采用一种基于风险的方法,以将测量、审计、跟踪、报告和执行要求纳入所有新的 RDS 政策中。在移交这一建议的过程中,董事会既未接受,也未拒绝该建议。董事会充分尊重 ICANN 社群不同部门的职权范围和职责,不会指示董事会或 ICANN 组织越权采取行动。建议要求开展在董事会职权范围外的工作或取得相应成果,这取决于社群的工作。董事会不能指示社群团体取得任何特定成果,董事会也不会启动任何政策制定工作。董事会注意到,在公共评议程序中除 RySG 外无人对此提出关切,RySG 发现该建议与社群已经制定或正在实施的政策存在重叠。董事会也记得 RDS-WHOIS2 实施指导人解释过该建议可以移交给 GNSO。因此,董事会将建议 CC.4 移交给 GNSO 理事会供其考量。

      董事会部分批准、部分移交给指定社群团体考量的建议

      建议 CC.1 呼吁董事会采取行动,处理因不正确的 RDS 联系数据而被暂停的 gTLD 域名。该建议要求制定政策,或者修改 RA 和 RAA。如上文所述,不管是哪种情况,董事会均无法保证任一流程的结果。如果 GNSO 理事会希望发起政策制定流程以解决 RDS-WHOIS2 建议,则董事会将此建议 CC.1 移交给他们进行处理。尽管董事会可以根据章程发起 GNSO 内部的政策工作,但董事会在回应 CCT-RT 建议时确认,董事会将把需要制定政策的建议移交给 GNSO 理事会,以示对 GNSO 政策角色以及社群发起政策制定流程特权的认可。此处没有理由不遵循这一先例。董事会也部分批准此建议,要求 ICANN 组织在下一轮 RA 和 RAA 合同谈判中予以讨论。RDS-WHOIS2 实施指导人确认对此建议采取的行动可包括董事会发起政策制定流程或合同谈判,而且由于董事会先前已认可社群依据特定审核小组建议发起政策制定的角色,董事会再次确认此角色。

      董事会拒绝的建议

      董事会拒绝建议 R11.1,因为该建议中提到的界面工具已不再使用,RDS-WHOIS 实施指导人也明确了这一点。2019 年 7 月,ICANN 组织推出了注册数据访问协议 (RDAP) 查找服务。这项新的查找服务对数据访问和查询响应格式进行了标准化,并允许数据搜索结果从服务器直接返回给终端用户,而无需通过 ICANN 组织服务器。由于 ICANN 不接触该数据,因此 ICANN 组织不收集或记录任何有关搜索查询返回了哪些数据的信息。当前的网络客户端无法支持建议中定义的衡量标准。尽管公共评议程序中表达了对 R11.1 的支持(例如:GAC“支持搜集 RDS-WHOIS 审核小组推荐的数据”),但 NCSG 的意见认为“此建议在 SSAD 开发出来后会变得多余”。RySG“不清楚 R11.1 中提到的针对常用 RDS 查找界面的 SLA,与注册管理机构和注册服务机构在响应 RDAP 查询时必须满足的 SLA 是否重叠或如何重叠”,并呼吁“在 ICANN 组织确定围绕界面采用哪些衡量标准之前对此问题给予”考虑。

      出于上述考虑,董事会认为其无法批准此建议,因为建议中提到的界面工具不再适用,而正在使用的系统无法修改以支持这项建议。此决定符合 RDS-WHOIS2 实施指导人于 2020 年 1 月 29 日与 RDS 董事会决策委员会小组进行讨论时做出的解释,即建议对当前版本的门户网站不适用。

      董事会也拒绝建议 BY.1,该建议提出更改章程中规定的 RDS 审核职权的范围。董事会指出建议中的语言可能会显著拓宽未来 RDS 小组的工作范围,而且还要求特定审核小组具备相关专长,能够鉴别“适用的”法律法规,然后解释如何调整当前实践以符合这些法律法规。对数据保护和数据转移法律持续开展跨辖区调查可能会非常昂贵,而且结合章程中当前定义的 RDS 审核的作用,这一工作的范围过宽。不同于建议中要求的较笼统的法律数据库范围,在这方面,目前章程中提到的 OECD 指南提供了客观的参考起点,即标准。该建议可能会扩大 RDS 审核范围,似乎也与社群就简化审核开展的持续对话背道而驰。由于建议的工作范围过宽且不现实,董事会拒绝这项建议,因为批准此建议似乎不符合 ICANN 的最佳利益。董事会指出,如果本届或未来的问责制和透明度审核小组建议更改 RDS 审核的范围(因为这属于 ATRT 的职权范围),则董事会将适时考虑此类建议。

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

      按照《ICANN 章程》的要求,2018 年 9 月,RDS-WHOIS2-RT 通过一个公共评议期征求了社群对其报告草案的意见,其中包含 23 条建议草案。论坛中总共发布了 7(七)份社群意见。此外,RDS-WHOIS2-RT 召开了合作交流会议,相关记录发布在其维基空间上9。RDS-WHOIS2-RT 汇总了其征询公众意见的方法,并在其最终报告的附录 H 中考虑了收到的意见。

      《ICANN 章程》要求公布最终报告以征询公众意见,以便为董事会对 RDS-WHOIS2 最终建议采取的行动提供参考。公共评议程序于 2019 年 10 月 8 日开始,并于 2019 年 12 月 23 日结束,总共收到了九条意见,董事会在评估最终建议时考虑了这些意见。

      董事会也通过 RDS 董事会决策委员会小组咨询了 RDS-WHOIS2 实施指导人的意见,获得了对部分建议的解释,以供董事会采取行动时参考。您可访问此处,了解关于这些互动的信息。

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

      RDS-WHOIS2-RT 最终报告的公共评议期所收到的社群意见摘要表明社群对该报告持不同的意见。尽管 ALACIPCBCGAC 和两位个人没有对任何建议提出关切,但 RrSGRySGNCSG 对部分建议提出了一些问题。这些问题包括但不限于:与正在进行的社群计划重叠,正在进行的社群工作对建议的可行性和存在理由的影响,与社群工作模式或要求的兼容性,资源的合理分配,对社群特权或政策流程的潜在干预以及总体可行性。

      公共评议程序体现了对最终报告的普遍认可,鉴于 RDS 格局的持续变化,RDS-WHOIS2 面临着挑战。对具体建议的关切和异议已在上文说明。

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

      对这些建议采取行动将有助于确保 ICANN 兑现其 RDS 相关承诺,增强 DNS 的安全、稳定与弹性。因这些建议而采取的潜在行动可能会影响社群带宽和资源,以及其他正在进行的工作。

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

      实施董事会根据平衡记分卡接受的 RDS-WHOIS2 建议将对组织产生预算影响。预计任何需要增量资源的建议都会纳入到运营规划和预算流程中,以便社群根据情况做出适当考量并排定计划工作的优先次序。

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

      此项董事会行动预计不会对与 DNS 有关的安全、稳定或弹性问题造成直接影响,尽管其结果可能会在未来产生影响。

      此项行动是否符合 ICANN 的使命?它与全球公共利益有什么关系?

      此项行动履行了《ICANN 章程》第 4.6 款的规定,符合 ICANN 的使命和职权范围,并符合公共利益。ICANN 审核是 ICANN 履行其承诺的过程中的一个重要基本组成部分。此次审核的范围与 ICANN 的以下承诺有着内在联系,即:改善通用顶级域名注册数据的准确度和访问权限,并考虑保护该类数据的保护措施。

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

      在董事会考量之前已收到公众意见。


1 2012 年 5 月,WHOIS 政策审核小组发布了 16 条建议。详情请参见:https://www.icann.org/resources/files/final-report-2012-05-11-en

2 RDS-WHOIS2 最终报告的阿拉伯语、西班牙语、法语、俄语和中文翻译可在 RDS-WHOIS2 最终报告公共评议期的第 III 部分找到 — https://www.icann.org/public-comments/rds-whois2-rt-final-report-2019-10-08-en

3 请参见 RDS-WHOIS2 最终报告第 125-127 页 — https://www.icann.org/en/system/files/files/rds-whois2-review-03sep19-en.pdf

4 详情请参见 2019 财年第四季度情况简报 — https://community.icann.org/download/attachments/64084088/RDS%20Fact%20Sheet%20%28June%202019%29.pdf?version=1&modificationDate=1565824368000&api=v2

5 请参见 RDS-WHOIS2-RT 最终报告附录 G(第 161 页)— https://www.icann.org/en/system/files/files/rds-whois2-review-03sep19-en.pdf

6 请参见 https://mm.icann.org/pipermail/rds-whois2-rt/2018-December/001026.html

7 详情请参见运营标准第 4.5 节。

8 详情请参见 https://community.icann.org/display/WHO/Implementation+Shepherds

9 请参见 https://community.icann.org/pages/viewpage.action?pageId=64084098

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