Skip to main content
Resources

通过的理事会决议 | ICANN 理事会例行会议

本页面还提供其他语种:

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

 

  1. 主要议程
    1. 任命 2015 年提名委员会主席和当选主席
  2. 认可议程:
    1. 批准董事会会议记录
    2. 任命本尼迪克特·阿迪斯 (Benedict Addis) 到安全与稳定咨询委员会 (SSAC) 任职
    3. 安全与稳定咨询委员会 (SSAC) 对戴维·康拉德 (David Conrad) 表示感谢
  3. 主要议程:
    1. 注册局服务技术评估小组 (RSTEP) 关于公益注册局申请技术捆绑 .NGO 和 .ONG 的报告
    2. 未来 gTLD 申请轮次规划
    3. 2015 财年运营规划和预算
    4. ICANN 五年战略计划终稿(2016 财年 – 2020 财年)
    5. 认可第二届一般会员峰会宣言
    6. 其他事务

 

  1. 主要议程

    1. 任命 2015 年提名委员会主席和当选主席

      鉴于 BGC 审核了 2015 年度提名委员会("NomCom")主席和当选主席候选人的意向书,考量了 2014 年度 NomCom 领导人全方位评估结果,并评估了每位候选人对 BGC 所提问题的回复。

      鉴于 BGC 已建议任命斯蒂芬·凡·吉尔德 (Stephane Van Gelder) 为 2015 年度 NomCom 主席。

      兹此发布第 2014.09.09.01 号决议:董事会特任命斯蒂芬·凡·吉尔德为 2015 年度提名委员会主席。

      第 2014.09.09.01 号决议的理由

      ICANN 章程要求董事会任命提名委员会 (NomCom) 主席和候任主 席。请参阅第 VII 条第 2.1 款和第 2.2 款:http://www.icann.org/en/general/bylaws.htm#VII。董事会已授权董事会治理委员会 (BGC) 承担推荐 NomCom 主席和当选主席供理事会批准的责任。请参阅 BGC 章程:http://www.icann.org/en/committees/board-governance/charter.htm。BGC 两次发布征求意向书 (EOI) 的公告(参阅 https://www.icann.org/news/announcement-2-2014-07-01-en),审核了收到的 EOI,并查看了 2014 年度 NomCom 领导人全方位评估,打算在推荐 2015 年 NomCom 当选主席前与部分候选人面谈。董事会已考量并同意 BGC 推荐的 2015 年 NomCom 主席,期待 BGC 在之后推荐 2015 年 NomCom 当选主席。董事会还想感谢所有有意成为 NomCom 领导人并提交了意向书的人士。

      通过公开 EOI 流程选拔和任命 NomCom 主席和当选主席对 ICANN 的透明度和问责制产生了积极影响,有利于公益事业。采纳 BGC 的建议不会对 ICANN 产生额外的财务影响,并且不会对域名系统的安全、稳定与弹性产生负面影响。

  2. 认可议程:

    1. 批准董事会会议记录

      第 2014.09.09.02 号决议:董事会批准 2014 年 7 月 30 日 ICANN 董事会会议的记录。

    2. 任命本尼迪克特 阿迪斯 (Benedict Addis) 到安全与稳定咨询委员会 (SSAC) 任职

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

      鉴于 SSAC 成员资格委员会代表 SSAC 要求董事会任命本尼迪克特·阿迪斯到 SSAC 任职。

      兹此发布第 2014.09.09.03 号决议:董事会任命本尼迪克特·阿迪斯到 SSAC 任职。

      第 2014.09.09.03 号决议的理由

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

      SSAC 能否作为合格的主体持续运营取决于同意自愿投入时间和精力来执行 SSAC 使命的优秀主题问题专家是否增加。本尼迪克特·阿迪斯是英国执法部门重案调查局 (SOCA) 网络取证部的一位技术官员。他有深厚的计算机科学和网络安全背景,这是其执法责任中不可分割的一部分。多年来,他一直积极侦办互联网滥用和互联网犯罪活动。阿迪斯先生可就政府政策和执法之间的交汇工作向 SSAC 提供极富价值的观点。

    3. 安全与稳定咨询委员会 (SSAC) 对戴维·康拉德 (David Conrad) 表示感谢

      鉴于董事会曾于 2011 年 3 月 18 日任命戴维·康拉德到 SSAC 任职。

      鉴于康拉德先生于 2014 年 8 月 1 日从 SSAC 辞职。

      鉴于 ICANN 积极肯定并真诚感谢康拉德先生在担任 SSAC 成员期间为社群提供的服务。

      兹此发布第 2014.09.09.04 号决议:董事会对戴维·康拉德在 SSAC 任职期间对 ICANN 所做的工作深表感谢,祝愿康拉德先生未来一切顺利。

      第 2014.09.09.04 号决议的理由

      依照惯例,SSAC 会在委员会成员离任时请求董事会对其服务作出认可。

  3. 主要议程:

    1. 注册局服务技术评估小组 (RSTEP) 关于公益注册局申请技术捆绑 .NGO 和 .ONG 的报告

      鉴于 2014 年 3 月 12 日,公益注册局 (PIR) 提交注册局服务评估政策 (RSEP) 申请 [PDF, 24 KB],请求在每一单个注册局协议的附件 A 中对二级域名 .NGO 和 .ONG 强制实施技术捆绑。

      鉴于 2014 年 5 月 21 日,ICANN 员工发布 RSEP 申请以公开信息,并依据 RSEP 审核了该申请。

      鉴于 2014 年 6 月 4 日,ICANN 员工的初步决定未发现任何重大的争用问题。此外,ICANN 员工确定,所申请的注册局服务可能产生重大的稳定性或安全性问题,并告知 [PDF, 320 KB] PIR 需要将该申请转呈注册局服务技术评估小组 (RSTEP) 进一步评估。

      鉴于 2014 年 6 月 6 日,ICANN 将 PIR 的 RSEP 申请转呈 [PDF, 952 KB] RSTEP 进一步评估。

      鉴于 2014 年 6 月 10 日,ICANN 发布 PIR 的 RSEP 申请以征询公众意见。公众意见征询期于 2014 年 7 月 30 日结束,未收到任何公众意见。

      鉴于 2014 年 7 月 29 日,RSTEP 报告发布以征询公众意见。公共评议期于 2014 年 8 月 13 日结束,未收到任何公众意见。

      鉴于 RSTEP 报告得出,从技术评估角度而言,该申请请求引入注册局服务支持对二级域名 .NGO 和 .ONG 强制实施技术捆绑,并不构成 RSEP 政策中规定的"会对稳定性或安全性产生严重负面影响的合理风险"。RSTEP 报告和员工还发现与引入所提新注册局服务到 DNS 相关的若干潜在技术和实施问题,包括:不捆绑 .NGO 和 .ONG 的影响,注册人和/或最终用户可能产生的混淆,在 IDN 变体背景下讨论的等同问题;以及其他运营问题。

      兹此发布第 2014.09.09.05 号决议:董事会通过 RSTEP 报告中的这一结论:PIR 的申请并不构成"会对稳定性或安全性产生严重负面影响的合理风险",批准关于引入注册局服务支持对二级域名 .NGO 和 .ONG 强制实施技术捆绑的 PIR 申请。

      第 2014.09.09.06 号决议:董事会授权总裁兼首席执行官或其指定人员为实施新注册局服务制定修正案,在其中考虑并妥善处理未决的相关技术和实施问题。

      第 2014.09.09.05 – 2014.09.09.06 号决议的理由

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

      2014 年 3 月 12 日,公益注册局(PIR,即 .NGO 和 .ONG TLD 的注册局运营商)申请提供新的注册局服务,以支持对二级域名 .NGO 和 .ONG 强制实施技术捆绑。该申请解释了所提技术捆绑、EPP 命令的执行、DNSSEC 的处理、二级 IDN 变体的处理,以及 WHOIS 服务。该申请通过注册局服务评估政策 (RSEP) 流程提交,转呈注册局服务技术评估小组 (RSTEP),且 RSEP 申请和 RSTEP 报告分别根据 RSEP 的要求开放了公众意见期。

      依据注册局服务评估政策 (RSEP) 第 2.7 条之规定,董事会收到注册局服务技术评估小组 2014 年 7 月 24 日的报告后,有 30 个日历日来做决定。董事会可决定:1) 批准该申请,2) 否决该申请,3) 推迟该申请,了解更多信息。

      正在考虑的提案是什么?

      董事会今日的行动是对 RSTEP 报告采取行动,该报告评估了与 PIR 的 RSEP 申请可能相关的安全性和稳定性问题。该申请请求实施一项新的注册局服务,对二级域名强制实施"技术捆绑"。PIR 的申请中写道:"技术捆绑包指一组两个域名,在不同的 TLD 中有相同的二级标签,都具有以下相同参数:

      • 注册商所有权
      • 注册和到期日期
      • 注册人、管理员、费用和技术联系人
      • 域名服务器关联
      • 域名状态
      • 适用的宽限期(追加宽限期、续用宽限期、自动续用宽限期、转让宽限期、赎回宽限期)
      • 它们至少有以下不同参数:"基于 RFC 5910 要求的 DS 记录。"

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

      ICANN 还启动了一个公众意见征询论坛,邀请社群对 PIR 的 RSEP 申请提供反馈,论坛开放期为 2014 年 6 月 10 日至 7 月 8 日。此次公共评议期内,未收到任何意见。要查看公众意见的最终报告,可访问:https://www.icann.org/public-comments/tech-bundling-2014-06-10-en

      此外,RSTEP 审核小组提供了咨询,对所申请注册局服务展开技术评估,了解对安全性和稳定性影响的可能性和严重性,以及所申请的注册局服务是否构成会对稳定性或安全性产生严重负面影响的合理风险。2014 年 7 月 24 日,RSTEP 报告 [PDF, 1.02 MB] 向 ICANN 社群发布。ICANN 启动了一个公众意见征询论坛,邀请社群对 RSTEP 报告提供反馈,论坛开放期为 2014 年 7 月 29 日至 8 月 5 日。此次公共评议期内,未收到任何意见。要查看公众意见的最终报告,可访问:https://www.icann.org/public-comments/rstep-technical-bundling-2014-07-29-en

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

      在 RSEP 申请和 RSTEP 报告的公共评议期内,均未收到任何意见。但是,RSTEP 报告和 ICANN 找到如下技术和实施问题,需要 PIR [和/或社群] 解决,制定 .NGO 和 .ONG 注册局协议修正案,以便实施新注册局服务:

      • 分析"解除捆绑"的影响,亦即在未来某个时间,PIR(或继任注册局)决定移除 .NGO 和 .ONG 之间的明确关联这一事件。
      • PIR 申请中包含一个主张,即 .NGO 和 .ONG 域名的内容"相同"(因此它们被捆绑到一起),但并无任何机制可在 DNS 的任何级别实施这一相似性,而网络服务器、邮件服务器等应用程序如果不经明确配置,不能理解 .NGO 和 .ONG 域名应等同对待。这可能导致客户端用户(例如,"为什么 EXAMPLE.SOMETHING.ONG 能解析而 EXAMPLE.SOMETHING.NGO 不能?")和注册人("为什么必须配置我的网络服务器理解 .NGO .ONG 两个二级域名下的每个三级域名?")产生混淆。要解决 PIR 申请中的这个潜在混淆,还需更多信息;
      • 对于 PIR 申请中包含的标签相似性问题(具体指两个标签被理解为"相同",即便组成这些标签的字符串不同),捆 绑是一个可能的解决方案。这个问题可能且将来可能被认为与"IDN 变体"问题的组成要素作用相同。社群已为寻找变体问题的解决方案躬耕数年,但尚未获得圆满的解决方案。 致力于变体问题的社群可能将接受 .NGO 和 .ONG 技术捆绑当作不妥当"终结"为处理变体而制定的政策和流程;以及
      • 有人认为技术捆绑是解决 IDN 变体问题的一个可能解决方案,但社群还未针对其使用制定框架,也还未批准此方法的实施。接受该 PIR 申请且不就技术捆绑进一步征询社群意见便推进,这可能令希望就 IDN 变体字符顶级域名的实施讨论此主题的 IDN 变体申请人和其他感兴趣的社群成员感到担忧。

      董事会审核了哪些重要材料?董事会认为至关重要的因素有哪些?

      董事会为采取今日的行动审核了多份材料。在审议是否批准该申请时,董事会还考虑了许多重要因素。董事会在审议中考量的重要材料和因素包括但不限于如下各项:

      是否会对社群产生积极或者消极影响?是否会在财务方面对 ICANN(战略计划、运营规划、预算)、社群和/或公众产生影响或不良后果?是否存在与 DNS相关的任何安全性、稳定性或灵活性问题?

      PIR 指出,引入强制性的技术捆绑具有双重优势:(1) 它消除了不同 gTLD 实体能注册相同二级域名时,合理预计可能接着发生的公众混淆。(2) 它为注册人提供防御性注册,确保 gTLD 能以透明、有效的方式关注其使命和外展。然而,尚需收集更多信息,才能了解此服务引入到 DNS 中得以更广泛应用会对社群造成其他哪些潜在影响。

      此注册局服务的最终实施可能对 ICANN、社群或公众产生财务影响,因为此注册局服务的更广泛应用可能涉及其他费用。

      RSTEP 报告就申请的此项注册局服务对安全性和稳定性的影响可能性和严重性展开了技术评估,结论是它并不构成会对稳定性和安全性产生严重负面影响的合理风险。

      各个社群尤其是对 IDN 变体感兴趣的社群已为找到标签相似性问题的方案辛劳数年,对于这个问题,.NGO 和 .ONG 的技术捆绑便是一例,但尚未达成圆满的解决方案。那些社群可能可对相似性问题的解决提供一些远见,咨询这些社群可能是妥当的做法。董事会的行动决不打算为 IDN 变体问题的处理形成一个先例或要求,不同情况必须单独评估。

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

      注册局服务评估政策属于一项 ICANN 共识性政策,自 2006 年 8 月 15 日起生效。为遵守 2014 年 7 月 29 日的政策,RSTEP 报告经发布以征询公众意见。公共评议期于 2014 年 8 月 13 日结束,未提交任何公众意见。此外,2014 年 6 月 10 日,ICANN 发布 PIR 的 RSEP 申请以征询公众意见。公众意见征询期于 2014 年 7 月 30 日结束,未提交任何公众意见。

    2. 未来 gTLD 申请轮次规划

      未达成任何决议。

    3. 财年运营规划和预算

      鉴于根据上一财年的众多社群商议以及全体 ICANN 员工和董事会财务委员会协商,2015 财年运营规划和预算草案已依照章程于 2014 年 5 月 8 日公布,以征询公众意见。

      鉴于确定 2014 年 5 月 8 日的 2015 财年运营规划和预算草案的重大修订时,考虑了干预活动和从公众意见论坛接收到的意见。

      鉴于除了公众意见论坛,ICANN 还通过包括在线电话会议、新加坡和伦敦会议以及电子邮件沟通在内的其他方式积极寻求社群反馈和与 ICANN 社群进行协商。

      鉴于董事会财务委员会已在近期举行的每次例会上讨论了 2015 财年运营规划和预算的制定工作,并对员工进行了指导。

      鉴于董事会财务委员会在 2014 年 8 月 19 日的会议上讨论了 2015 财年运营规划和预算终稿,并建议董事会通过 2015 财年运营规划和预算。

      鉴于根据 2001、2009 和 2013 注册商授权协议第 3.9 款,董事会将设立制定年度预算所必需的注册商可变授权费。

      鉴于 2015 财年运营规划和预算中已纳入 2015 财年注册商费用(包括建议的注册商可变授权费)的说明。

      兹此发布第 2014.09.09.07 号决议:董事会采纳 2015 财年运营规划和预算,同时根据 2015 [PDF, 621 KB] 财年运营规划和预算中的陈述设立可变授权费(按每个注册商和每笔交易)。

      第 2014.09.09.07 号决议的理由

      根据《ICANN 章程》第 XVI 条第 4 款,董事会将通过一项年度预算并在 ICANN 网站上予以公布。2014 年 5 月 8 日,ICANN 公布了2015 财年运营规划和预算草案,以征询公众意见。该版本以数月以来与执行团队的多次讨论,以及与 ICANN 支持组织、咨询委员会和其他利益主体组织的广泛协商为基础。由于干预活动和从公众意见论坛接收到的意见,ICANN 对 2014 年 5 月 8 日公布的 2015 财年运营规划和预算草案进行了一些有限但重大的修订。

      通过所有方式接收到的所有意见都在制定 2015 财年运营计划和预算终稿过程中得到了考虑,并在可行和适当的时候得到了采纳。

      除了日常运营要求外,2015 财年运营规划和预算还包括 2015 财年的新 gTLD 预算项目,以及分配给所收到的来自社群领导的 2015 财年预算申请中各项内容的金额。年度预算还披露了新 gTLD 项目的影响。而且,由于注册商可变授权费是制定预算的关键,因此 2015 财年运营规划和预算说明并设立了这些费用,这符合近年来的趋势,并将由注册商审批。

      由于 2015 财年运营规划和预算提供了一个适当的框架,ICANN 将通过该框架进行管理和运营,因此该预算将产生积极影响。它还为组织的透明度和责任性提供了基础。这将对 ICANN 和所针对的社群产生财务影响。就针对域名系统 (DNS) 安全性、稳定性和灵活性方面的资金而言,此项预算只会对域名系统的安全性、稳定性和灵活性产生积极影响。

    4. ICANN 五年战略计划终稿(2016 财年 – 2020 财年)

      此议项已取消。

    5. 认可第二届一般会员峰会宣言

      鉴于第二届一般会员峰会 (ATLAS II) 已于 2014 年 6 月在英国伦敦的 ICANN 50 会议举行。

      鉴于 ATLAS II 构建于 2009 年 3 月在墨西哥 ICANN 34 会议期间组织的第一届峰会基础上。

      鉴于董事会已收到 ATLAS II 宣言终稿 (https://community.icann.org/ download/attachments/48338039/ATLAS-II-Declaration-with-appendix-RC9.pdf?version=1&modificationDate=1407420726000&api=v2) [PDF, 204 KB]。

      鉴于一般会员社群延续了峰会的热情参与精神,开展了一系列 ATLAS II 后续实施活动。

      兹此发布第 2014.09.09.08 号决议,董事会认可 ATLAS II 宣言终稿,顺祝伦敦 ICANN 50 期间圆满举行的峰会!

      第 2014.09.09.09 号决议,董事会肯定 ATLAS II 峰会及其成果的重要性,认为它们是个人互联网用户组成的一般会员社群为强大 ICANN 而提出的宝贵意见。

      第 2014.09.09.10 号决议,董事会感谢一般会员社群为举行一般会员峰会、发布 ATLAS II 宣言终稿和实施 ATLAS II 后续实施活动而付出的巨大努力。

      第 2014.09.09.11 号决议,董事会期待就 ATLAS II 宣言终稿向董事会提出的所有意见,跟进 ALAC 的活动。

      注:董事会的三位投票成员放弃对这些决议投票。他们发言存档称,他们支持 ATLAS的工作,但希望注意,他们鼓励董事会以后考虑将 ATLAS发展成为定期活动的计划。

      第 2014.09.09.08 – 2014.09.09.11 号决议的理由

      第二届一般会员峰会 (ATLAS II) 的举行归功于董事会为该活动批准一项特别预算,这才有 ATLAS II 宣言的发布。此宣言由奥利维尔•科雷鹏-勒布朗 (Olivier Crépin-Leblond) 于 2014 年 8 月 7 日发送给史蒂夫•克罗格 (Steve Crocker)。

      此文档源于在 2014 年 6 月伦敦参加面对面会议的大约 150 个一般会员组织付出的工作,这些组织遍布 70 个国家/地区。

      宣言包含了全部 5 个 ATLAS II 主题工作组的工作:

      • 主题工作组 1 (TG1):多利益相关方模式之未来
      • 主题工作组 2 (TG2):ICANN 全球化
      • 主题工作组 3 (TG3):全球互联网:从用户角度出发
      • 主题工作组 4 (TG4):ICANN 的透明度和责任制
      • 主题工作组 5 (TG5):一般会员社群参与 ICANN

      它共有 43 条建议,面向 ICANN 董事会、ICANN 和 ALAC,编号 R-1 至 R-43。它还包含面对更广大的互联网社群的 10 条观察意见,编号 O-1 至 O-10。

      一般会员社群目前正通过一个特别工作组,启动建议和观察意见的实施工作。

      ALAC 正就此宣言征求更广大的 ICANN 社群的反馈。

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

    6. 其他事务

      未达成任何决议。

resolutions-09sep14-zh.pdf  [240 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."