Skip to main content
Resources

通过的理事会决议 | ICANN 理事会特别会议

本页面还提供其他语种:

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到: http://www.icann.org/en/groups/board/documents/resolutions-27jun13-en.htm

 

  1. 认可议程
    1. 批准理事会会议记录
    2. 任命 Ben Butler 到 SSAC 任职
    3. 批准 AROS 合同协议
  2. 主要议程
    1. 更新 IDN ccTLD 快速通道实施
    2. 批准 2013 RAA
  3. 执行会议
    1. 保密决议

 

  1. 认可议程:

    1. 批准理事会会议记录

      第 2013.06.27.01 号决议:理事会批准 2013 年 5 月 18 日的 ICANN 理事会例行会议记录。

    2. 任命 Ben Butler 到 SSAC 任职

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

      鉴于SSAC 成员资格委员会代表 SSAC 要求理事会任命 Ben Butler 到 SSAC 任职。

      第 2013.06.27.02 号决议:理事会任命 Ben Butler 到 SSAC 任职。

      第 2013.06.27.02 号决议的理由

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

      SSAC 能否作为合格的主体持续运营取决于已同意自愿投入时间和精力来执行 SSAC 使命的优秀主题专家是否增加。Ben Butler 会为 SSAC 带来宝贵的技能。具体来说,他会带来作为 GoDaddy(一家大型注册服务商)网络滥用部门主管的经验。此外,Butler 先生还能带来作为托管服务商的经验,以及与其他托管服务商的人脉关系,这两样都是 SSAC 需要补充的。最后,他还能带来有关 DNS 滥用问题的丰富知识。

    3. 批准 AROS 合同协议

      鉴于理事会已经审核了 ICANN 工作声明提案的相关条款;

      鉴于需要获得批准才能履行提供 650,450 美元 ICANN 资金支持的承诺;

      鉴于协议生效能保证这款工具的开发,从而为注册管理机构和注册服务商委任提供支持;

      第 2013.06.27.03 号决议:理事会授权总裁兼首席执行官与 Solutions Street 签订协议提案。

      第 2013.06.27.04 号决议:批准关于批准与 Solutions Street 签订自动化注册服务商纳入系统 (AROS) 开发合同的请求。

      第 2013.06.27.03 — 2013.06.27.04 号决议的理由

      ICANN 支出政策限制 ICANN 工作人员签订每个义务事项金额超过 50 万美元的合同以及支付同等金额的款项。因此,ICANN 秉持该政策,寻求理事会的批准,以履行每个合同事项超过 50 万美元的合同义务。ICANN 确定了构建 AROS 系统的供应商,并与该供应商签订了金额预计为 650,450 美元的合同(包括许可)。

      提议的解决方案是为 ICANN 委任的注册服务商开发自动化注册服务商纳入系统 (AROS)。本文档中说明的系统旨在为注册服务商提供一致的用户界面,以便管理注册服务商的相关信息,并在请求(主要)通用顶级域名注册管理机构的委任时,提供注册管理机构用以管理注册服务商的委任请求的工作空间,以及便于 ICANN 指定的管理员管理 AROS 的管理界面。

      工作组 (WG) 提出了对系统的要求,该工作组成员包括注册管理机构和注册服务商利益主体组织代表、ICANN 工作人员及专门研究需求的外部顾问。注册管理机构和注册服务商代表(各三名)是由各自的利益主体主席确定的志愿者。除了上述工作组,工作人员还与注册管理机构和注册服务商一起对两种情况进行了调查,以确认要求。

      理事会批准签订这一合同义务将对机构群体产生积极影响,因为它为注册管理机构和注册服务商签订合同提供了更及时有效的方法。通过这一举措,ICANN 正逐步创造更具竞争力和更有效的环境。该决议对 ICANN 会产生财务影响,但所有这些影响在获得批准的 2013 财年预算以及 2014 财年预算草案中均有所预计。此举不会引起与域名系统相关的任何安全性、稳定性或灵活性问题。

  2. 主要议程:

    1. 更新 IDN ccTLD 快速通道实施

      鉴于 ICANN 理事会于 2009 年 10 月 30 日批准了快速通道实施计划(http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2);

      鉴于根据 IDN ccTLD 快速通道流程,技术和字符串相似性评估(DNS 稳定性评估)这两项工作均由一个独立的专家小组执行;

      鉴于 ccNSO 提出了在 IDN ccTLD 字符串选择政策中纳入对字符串相似性评估执行两个审核小组流程的建议,并且 ccNSO 委员会通过了该建议 (http://ccnso.icann.org/node/38787 [PDF, 119 KB]);

      鉴于 ICANN 收到了机构群体要求提高字符串相似性评估的透明度和一致性的各方意见和建议,包括政府咨询委员会提出的建议;

      鉴于 ccNSO 主席请求 ICANN 理事会在 IDN ccTLD 快速通道流程中对字符串相似性审查执行两个审核小组流程;

      第 2013.06.27.05 号决议:ICANN 理事会批准修正快速通道实施计划,在 IDN ccTLD 快速通道流程中对字符串相似性审查执行两个审核小组流程。指示总裁兼首席执行官将此修正案纳入 ICANN 理事会早前于 2009 年 10 月 30 日采纳的快速通道实施计划(于 2011 年 12 月 8 日修订)中,并尽快实施此修正案。

      第 2013.06.27.06 号决议:ICANN 理事会批准修正快速通道实施计划,这样在新的扩展流程相似性审核小组 (EPSRP) 成立后,快速通道流程中 IDN ccTLD 字符串的所有未决请求便可选择请求该小组进行评估。

      第 2013.06.27.05 — 2013.06.27.06 号决议的理由

      p>为什么理事会要在当下解决此问题?

      CcNSO IDN ccTLD PDP 即将完成。在期望的政策建议中,有一个提案是对申请的 IDN ccTLD 字符串的易混淆相似性审查执行两个审核小组机制。由于引入 IDN ccTLD 快速通道的目的之一是试验 IDN ccTLD 字符串的选择方法,因此在满足引入 IDN ccTLD 的短期需求的情况下还需要执行 ccNSO 政策制定流程。通过在快速通道流程中试验引入两个审核小组机制,可根据需要测试并完善提议的两个审核小组机制和方法。此外,也希望通过这种方式修改快速通道流程,从而实现满足继续引入 IDN ccTLD 的短期需求的目标。最后,机构群体长期以来一直要求修改快速通道流程中的字符串相似性审查,并且在此遵循 ccNSO 的指导原则将增强 ICANN 的问责制。

      正在考虑的提案是什么?

      提议修改快速通道实施计划是为了引入第二个独立专家小组,在易混淆的相似性方面审查 IDN ccTLD 快速通道字符串。这是对现有字符串相似性审核小组的补充。此外,该提案还规定,所有未决的快速通道 IDN ccTLD 字符串请求(包括之前未通过字符串相似性审查的请求)可以选择请求 EPSRP 审查其申请。这将使所有未决和未来的申请都经历一致的评估,而不会对已成功通过快速通道流程的申请造成影响。成功通过的申请在任何情况下都不需要接受 EPSRP 审查。

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

      字符串相似性问题是迄今为止两届 IDN ccTLD 快速通道流程年度审查的焦点。自 2011 年 3 月在旧金山举行的 ICANN 会议以来,已在 ccNSO 会议期间举行的公开会议上进行了讨论。

      2013 年 4 月,ccNSO 委员会通过了关于 IDN 国家或地区代码政策制定流程的最终报告 (http://ccnso.icann.org/workinggroups/idn-ccpdp-final-29mar13-en.pdf [PDF, 376 KB])。

      该报告包括 IDN ccPDP 工作组 1 (IDN ccPDP WG 1) 的提案,该提案已经历了广泛的公共意见征询流程。IDN ccPDP WG 1 重点致力于对与 ISO 3166-1 列表中列出的地区相关的 IDN ccTLD 选择政策草案提出建议,这些建议应适时替换 IDN ccTLD 快速通道方法。提案包括为字符串易混淆的相似性验证引入两个专家小组,由第二个专家小组根据科学研究对字符串进行最终的确切审查。在两届年度审查期间收到的公众意见都支持引入第二个专家小组。此外,政府咨询委员会还建议 ICANN 理事会:

      • 重新考虑最近在快速通道流程中被拒绝的 IDN,特别是公共或国家管理机构提名的 IDN。
      • 创建申诉机制,允许在不影响前一项内容及透明度和问责制目标的情况下,对与提议的 IDN ccTLD 相关的易混淆性决定提出质疑。

      虽然 EPSRP 不是申诉流程,但它也会单独提供与现有字符串相似性审核小组类型不同的字符串相似性审查。EPSRP 的引入也将提供一条途径,以便审查未成功通过现有字符串相似性审核小组审查的 IDN ccTLD 快速通道申请人。这样,采取这一举措将解决 ccNSO 机构群体提出的建议及 GAC 建议。

      是否会对 ICANN 产生经济影响或不良后果?

      此修正案将包含预算,因为 ICANN 将选任第二个专家小组对请求的 IDN ccTLD 字符串执行第二次验证和最终验证。此修正案预计不会对 DNS 的安全性和稳定性造成任何影响。

    2. 批准 2013 RAA

      鉴于 ICANN 与注册服务商利益主体组织选出的小组"注册服务商协商团队"自 2011 年起就对 ICANN 的 2009 年《注册服务商委任协议》(RAA) 修正案进行了协商。

      鉴于协商得出了 2013 RAA 提案,该提案不仅解决了执法机构对 2009 RAA 提出的全部 12 条建议,并且还处理了其他修订内容。

      鉴于 ICANN 致力于在通过新 gTLD 计划授权 gTLD 前确定 2013 RAA。

      鉴于 ICANN 和注册服务商需要足够的时间来过渡到 2013 RAA 的各项条款,并且理事会的批准将为适用条款提供必要保证。

      第 2013.06.27.07 号决议:理事会批准 2013 RAA 的形式。

      第 2013.06.27.08 号决议:指示总裁兼首席执行官采取所有必要措施,与所有有资格的注册服务商和注册服务商申请人一起贯彻落实 2013 RAA。

      第 2013.06.27.09 号决议:理事会感谢注册服务商利益主体组织,特别是注册服务商协商团队的成员在协商过程中投入的时间精力和付出的巨大努力。

      第 2013.06.27.07 — 2013.06.27.09 号决议的理由

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

      关于 2013 RAA 的长期协商已划上圆满句点,2013 RAA 提案已提交至理事会。此时批准 2013 RAA 非常重要,因为理事会已接受 GAC 在北京公报中的建议,即 "应在批准任何新 gTLD 合同前最终确定 2013 年《注册服务商委任协议》"。现在批准 2013 RAA 能使理事会满足这一建议。此外,ICANN 已多次向机构群体表示,将在授权新 gTLD 前确定 2013 RAA。现在批准 2013 RAA 还可让 ICANN 和注册服务商确定新条款的适用性,并使 ICANN 和注册服务商能够继续开展实施工作,以履行更高义务。最后,ICANN 机构群体自 2011 年末开始协商后就对新版 RAA 拭目以待。

      正在考虑的提案是什么?

      2013 RAA 规定通过进一步更新合同框架来保护注册人。2013 RAA 是对整个协商过程中提出的许多关键问题以及公众意见征询期提出的问题作出艰难让步后才取得的成果。2013 RAA 体现了对当前 2009 RAA 的重大改进,并大大提高了每个 ICANN 委任的注册服务商的服务执行要求,因而为域名生态系统带来了显著改善。

      2013 RAA 提案的要点包括:

      • 对协商起推动作用的 12 条执法机构建议在该提案草案中都得到了解决。随附的《执法机构汇总表》列出了 2013 RAA 中解决每条建议的章节或规范。部分要点包括让每个注册服务商确定一位滥用问题联系人、要求在注册人和帐户持有人级进行 Whois 验证和确认、更严格地规定注册服务商对于分销商以及新数据保留的义务。

      • 增强的合规工具,包括范围更广的暂停和终止工具、对促进正在进行的调查的审计权和信息访问权的说明,以及年度认证要求。

      • 注册人权利和责任文档,使用简单明了的语言说明 2013 RAA 中规定的权利和责任,例如注册人希望获得的关于注册的条款与条件、费用和客户服务流程的信息类型。该文档同时强调了注册人在提供准确联系信息方面的角色,以及在维护域名注册方面的责任。列举的权利和责任并未涵盖共识性政策中规定的所有注册人权利和责任,但该文档与 2013 RAA 的条款紧密相连。

      • 注册服务商对于分销商的责任符合 RAA 的所有相应条款。

      • 与新 gTLD 注册管理机构协议合并。 ICANN 和注册服务商 NT 已同意在适当的情况下呼应注册管理机构协议的表述,以使合同更好地保持一致。新 gTLD 注册管理机构协议和 2013 RAA 有望互补,因为注册管理机构和注册服务商正努力达成能更好地反映不断变化的市场的协议。

      • 代理与隐私服务提供商临时要求。 ICANN 和注册服务商 NT 已同意为通过注册服务商提供的代理和隐私服务提供临时保护。这些临时保护将要求获得客户服务流程等项目的信息,以及提供商传达有关域名注册底层用户的信息的时间。尽管这些保护并未涵盖所要求的对代理和隐私服务提供商采取的所有措施,但这些临时保护能在制定正式的委任计划前提供更有责任感的市场。

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

      由于执法群体提出了提案,因此启动了 RAA 协商。在整个协商过程中,ICANN 和注册服务商 NT 就如何实施 12 条执法机构建议咨询了执行部门和政府咨询委员会 (GAC) 的代表。有关如何将执法机构建议纳入 2013 RAA 的摘要,请访问 http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm。GAC 对将 2009 年 GAC 执法机构建议纳入其中的 RAA 的改进表示感谢,同时对提供验证和改善注册人数据准确性所取得的进展感到高兴,并支持持续努力确定有助于防止犯罪或其他非法活动的预防性机制。

      除了咨询执法机构和 GAC,ICANN 还在哥斯达黎加、布拉格、多伦多和北京会议期间召开了 RAA 协商公开互动会议。ICANN 工作人员代表也根据要求向 GNSO 委员会、网络普通用户工作组、GNSO 的各个社群和利益主体组织以及执法机构代表发表了演讲。另外,ICANN 已公开发布了 RAA 的三个版本,并于 2013 年 3 月到 2013 年 4 月间征询了公众意见。2013 年 4 月 22 日的公众意见征询关于包含 ICANN 与注册服务商 NT 之间所有协议的 2013 RAA 最终提案。十九位评论家参与了 2013 年 4 月 22 日的公众意见论坛,其中包括注册服务商利益主体组织、ALAC、知识产权社群和企业社群的代表。为支持 2013 RAA 最终提案的发布,ICANN 于 2013 年 5 月召开了一次互动网络会议,100 多名与会者通过电话和 Adobe Connect 参加了此次会议。

      在审查公众意见后,ICANN 再次向注册服务商协商团队进行了咨询,以便确认注册服务商对确定更改的支持。

      机构群体有什么疑虑或提出了哪些问题?

      在整个协商过程中,机构群体就纳入协商考虑范围的 RAA 提案中的各种问题提出了疑虑。例如:部分机构群体提出了对政策制定流程以外的代理和隐私服务标准过度发展的高度关注。因此,ICANN 和注册服务商 NT 确定了一项解决方案,即制定了注册服务商应用于注册时提供的代理和隐私服务的最低标准,同时提出了机构群体参与制定代理/隐私委任计划的方法。但是,这并未减少这方面的所有疑虑,也无法通过这种方式解决所有疑虑。

      随着 2013 RAA 提案的最终发布,所提出的问题主要集中在以下几个方面:

      • 对于 Whois 准确性,IPC、BC 和其他评论家支持采用预决议验证,而不是在提出决议后留出可进行验证的 15 天时限。在之前的协商中就提出过预决议验证的请求,由于可能对域名注册流程做出重大更改,以及正在努力制定处理 gTLD 注册数据的新方法,因此决定向机构群体解释,在没有进一步的机构群体工作和进展的情况下,此时引入预决议验证并不适合。

      • 同样还提出了验证电子邮件和电话号码的请求,在注册服务商和其他机构群体看来,执行电话验证也不一定可行,甚至在世界上的某些地区几乎无法实现。为支持正在对 gTLD 注册数据开展的工作,延迟了对这方面的进一步更改。

      • 对于通过代理和隐私服务提供商进行的注册,多位评论家要求(与他们在整个 RAA 制定流程中要求的一样)对基本用户资料进行验证。正如我们之前向机构群体做出的解释,我们马上就会开展代理和隐私委任计划的政策工作,以便制定此类要求,因为在这种情况下实施的流程将更为清晰。此外,机构群体中的众多成员反对在此时引入此类要求。同样,机构群体目前并未就更明确地要求披露和传达基本用户资料的机制达成一致,并且尽管许多意见认为 ICANN 应立即制定此类要求,但此项工作也已被延迟到有关委任的基于更大机构群体的政策工作中。对于 2013 RA 中规定的代理/隐私义务,最近提出了一个共同关心的问题,即我们需要更加明确分销商的适用性,ICANN 已开始处理这一更改,并且根据理事会的批准反映在 2013 RAA 中。

      • 一些评论家提出了对于新注册人权利和责任文档的关注,指出该文档在明确更多一般权利和责任方面做得远远不够。由于注册人权利和责任规范的特定目的是跟踪 2013 RAA 的条款,因此我们阐明了文档标题。如果机构群体希望对权利和责任发表更广泛的声明,2013 RAA 将不会妨碍这项工作。

      • 一些评论家指出,如果 ICANN 希望不顾注册服务商的反对而将修正案落实到位,那么确定的修订流程太过繁琐。但是,ICANN 认为 2013 RAA 中反映的理事会批准的修订流程具有平衡作用,可明确在多利益主体模式下制定政策的作用,虽然复杂,但在需要实行的时候可提供强有力的机制。

      • 尽管评论家普遍支持 2013 RAA 及其带来的改进,但这些评论家中的许多人都提出了对制定 2013 RAA 流程的不满。许多人的不满之处在于协商是双边协商,甚至没有为机构群体提供对协商会议提意见的机会,更不用说在协商期间发表意见。修改之前采用的流程已经来不及了,此时重要的是记得 RAA 本身并不包含任何协商途径;要采用的流程并不明确。为确保机构群体能够对以后的 RAA 修订发表意见,RAA 现在规定在对修订进行考量或协商时需要明确征询公众意见。

      此处的内容是所提出的一些关键问题的摘要。关于 RAA 最终提案的意见的完整摘要和分析(发布于 [插入链接])也被视为 RAA 决策的一部分。该摘要和分析还确定了 2013 RAA 针对收到的意见进行修改的领域。

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

      理事会审核了:

      • 2013 RAA 和纳入的规范
      • 2013 RAA 对比 2013 年 4 月 22 日版本的更改摘要
      • 咨询注册服务商后对 RAA 进行的最终说明
      • 2013 年 4 月 22 日的公众意见摘要和分析
      • 2013 年 3 月的公众意见摘要和分析
      • 处理执法机构建议的摘要
      • GAC 北京公报

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

      理事会认为在做出此项决定的过程中许多因素都至关重要。首先是注册服务商 NT 的热切参与,以及注册服务商机构群体对 2013 RAA 发表的支持声明。其次是 2013 RAA 纳入了 12 条 GAC 执法机构建议,构成了开放协商的基础,而 GAC 对协商结果的支持是支持 2013 RAA 的主要因素。再则,虽然 ICANN 机构群体希望在某些方面看到 2013 RAA 做出更改,但机构群体声明压倒性地支持新 RAA 中取得的成就。由于具有继续处理机构群体确定为问题的主要方面的方法(包括 gTLD 注册数据专家工作组和对隐私/代理委任计划所做的工作),因此机构群体能够继续讨论此次协商中提出的一些更具挑战性且处理程度尚未达到机构群体某些成员要求的问题。2013 RAA 中的改进(包括增强的合规工具、Whois 进展、分销商的义务更明确)非常及时,并应在授权新 gTLD 前实施,以便这些条款能涵盖加入新 gTLD 计划的所有 gTLD。

      最后,理事会认为意义重大的一点是,注册服务商利益主体组织支持 2013 RAA。

      理事会考虑了哪些替代方案?

      由于 2013 RAA 向理事会提出了方法,因此除了延迟批准协议外,理事会没有考虑任何其他方案。但是,理事会审核了机构群体对于作为替代方案应添加到 2013 RAA 或从中删除的条款的建议。

      会对机构群体产生积极还是消极影响?

      2013 RAA 的引入有望产生积极影响,因为即将进行的更改和加强的义务预计会使注册服务商在 DNS 中的角色日渐成熟。2013 RAA 将协助 ICANN、注册服务商和注册人,更清晰地了解义务、权利和信息访问。最有可能产生消极影响的风险将来自于缺乏对新义务的了解 — 注册人和注册服务商都将面临新的要求。教育培训工作有助于抑制这些消极影响。

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

      2013 RAA 规定的新义务将对注册服务商造成财政影响,因为根据协议,他们将要承担新的运营义务,并且需要修改体系和流程以履行这些义务。2013 RAA 包含过渡条款,可为实施提供时间。同样地,ICANN 也将修改其合同履行活动,这可能会产生极小的财务影响,因为合同合规团队的发展已纳入了预算。帮助确保注册服务商和注册管理机构都能了解这些新义务所需的教育外展也会要求利用 ICANN 的财务资源。注册服务商运营成本的增加可能会导致用户费用增加,但目前尚无相应文档印证这一情况的发生。

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

      2013 RAA 包含 IDN 和 DNSSEC 支持等技术要求,将致力于维护 DNS 的安全性、稳定性和灵活性。

      这属于组织管理职能,已为其听取了公众意见。

  3. 执行会议

    1. 保密决议

      [编辑决议]

      第2013.06.27.13 号决议:根据《ICANN 章程》第 III 条第 5.2 款,本决议的特定款项仍将作为"与人事或雇用事宜相关的行动"予以保密,并且根据同一章程条款,在等待总裁兼首席执行官确定可以公布非保密部分之前,整个决议仍应予以保密。

      第 2013.06.27.10 — 2013.06.27.13 号决议的理由

      [编辑理由]

resolutions-27jun13-zh.pdf  [344 KB]

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