Skip to main content
Resources

会议记录| ICANN 董事会例行会议

本页面还提供其他语种:

2014 年 9 月 9 日,ICANN 董事会在土耳其伊斯坦布尔于当地时间下午 4:15 召开了例行会议。

主席史蒂夫•克罗克 (Steve Crocker) 准时宣布会议正式开始。

以下董事参加了全部或部分会议:塞巴斯蒂安•巴肖莱 (Sébastien Bachollet)、谢林•查拉比 (Cherine Chalaby)、法迪•切哈德先生(Fadi Chehade,总裁兼首席执行官)、克里斯•迪斯佩恩 (Chris Disspain)、比尔•格兰厄姆 (Bill Graham)、沃尔夫冈•科纳沃茨特 (Wolfgang Kleinwächter)、布鲁斯•托金(Bruce Tonkin,副主席)、麦克•西尔柏 (Mike Silber)、贡萨洛•纳瓦罗 (Gonzalo Navarro)、乔治•萨多夫斯基 (George Sadowsky)、奥尔加•马德鲁加–福蒂 (Olga Madruga–Forti)、布鲁诺•朗万 (Bruno Lanvin)、埃里卡•曼 (Erika Mann) 和吴国维 (Kuo–Wei Wu)。

以下董事因未能参加会议而表示歉意:雷•普拉扎 (Ray Plzak)。

以下董事会联络人参加了全部或部分会议:希瑟•德莱顿(Heather Dryden,GAC 联络人)、拉姆•莫汉(Ram Mohan,SSAC 联络人)、约恩内•索恩宁(Jonne Soininen,IETF 联络人)和苏珊•伍尔夫(Suzanne Woolf,RSSAC 联络人)。

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

受邀与会者:里纳利亚•阿卜杜尔•拉希姆 (Rinalia Abdul Rahim)、马库斯•库默尔 (Markus Kummer) 和阿莎•合美嘉妮 (Asha Hemrajani)

以下 ICANN 高级管理人员和工作人员参加了全部或部分会议:阿克兰•阿特拉(Akram Atallah,全球域名部门总裁)、苏珊娜•贝内特(Susanna Bennett,首席运营官)、梅根•比舍朴(Megan Bishop,董事会支持协调人)、戴维•奥利弗(David Olive,政策制定副总裁)、哈维尔•卡尔维兹(Xavier Calvez,首席财务官)、莎曼珊•艾斯内(Samantha Eisner,资深法律顾问)、Vinciane Koenigsfeld(文希安•柯尼希斯费尔德,董事会支持内容经理)、埃里卡•兰德尔(Erika Randall,法律顾问)、阿什文•兰根(Ashwin Rangan,首席创新与信息官)、艾米•斯塔索斯(Amy Stathos,副总法律顾问)和特里莎•斯旺哈特(Theresa Swinehart,全球战略总裁高级顾问)。

  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 年提名委员会主席和当选主席

      谢林•查拉比提出决议提案,并得到克里斯•迪斯佩恩的支持。

      布鲁斯•托金介绍了此议程事项,并指出董事会治理委员会建议任命斯蒂芬•凡•吉尔德 (Stephane Van Gelder) 为 2015 年度提名委员会主席。BGC 将在晚些时候推荐 2015 年度提名委员会当选主席。

      主席建议进行投票,董事会采取了以下行动:

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

      鉴于 BGC 已建议任命斯蒂芬•凡•吉尔德为 2015 年度 NomCom 主席。

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

      十三位董事会成员投票赞成第 2014.09.09.01 号决议。法迪•切哈德、塞巴斯蒂安•巴肖莱和雷•普拉扎未能对决议投票。决议通过。

      第 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. 任命本尼迪克特•阿迪斯到安全与稳定咨询委员会 (SSAC) 任职

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

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

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

      第 2014.09.09.03 号决议的理由

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

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

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

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

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

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

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

      第 2014.09.09.04 号决议的理由

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

    4. 董事会出席会议的所有成员投票赞成第 2014.09.09.02、2014.09.09.03、2014.09.09.04 号决议。法迪•切哈德、塞巴斯蒂安•巴肖莱和雷•普拉扎未能对这些决议投票。决议通过。

  3. 主要议程:

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

      在考虑此问题之前,拉姆•莫汉确定,由于他的任职关系,他与该事项存在利益冲突。但由于拉姆有此方面的专门知识,他受邀参加讨论。

      乔治•萨多夫斯基提出决议提案并得到布鲁斯•托金的支持。

      主席介绍了此议程事项,并提供了有关注册局服务评估小组 (RSEP) 和注册局服务技术评估小组 (RSTEP) 的背景信息。主席解释说,该流程分为两个层面。RSEP 负责请求的合同更改,并由工作人员进行处理。如果请求的合同更改包括可能会产生安全影响的技术更改,则由 RSTEP 在专家组参与的情况下进行辅助性评估。RSTEP 提交报告后,董事会有 30 天时间做出决定。主席表示,关于 RSEP/RSTEP 规则是合适还是应进行调整,尚存在问题,但这不是目前的讨论主题。

      随后,主席简要概述了 RSTEP 有关公共利益注册局 (PIR) 请求对二级域名 .NGO 和 .ONG(英语和法语版本的 TLD 字符串)强制实施技术捆绑的报告。他指出,根据该报告,并不存在与上述请求有关的安全性和稳定性问题,但也不能保证会永久保持这种协调性;同时,该报告建议在合同签署流程中处理某些细节问题。

      里纳利亚•阿卜杜尔•拉希姆询问董事会允许 PIR 请求对二级域名 .NGO 和 .ONG 实施技术捆绑是否会影响国际化域名 (IDN) 变体的处理。拉姆•莫汉解释说,ccTLD 方面已存在捆绑的先例。以中国、香港和台湾为例,已经为它们分配了多个 TLD,并且这些 TLD 正以捆绑方式根据政策而不是技术协作运行。拉姆进一步解释称,具体到 PIR,.NGO 和 .ONG TLD 明显不具相似性,而且含义也不同,除非你了解其中一个是法语语系,另一个是英语语系。此外,如果将到目前为止生成的规则应用于 IDN 变体,则 PIR TLD 仍然符合条件,因为这两个 TLD 均为已在 TLD 的最小字符集中被接受的 ASCII 名称。拉姆还表示,通常,在 IDN 变体方案中,具有变体的字词也会造成问题;但是,这里的 TLD 是两个单独的缩写。苏珊•伍尔夫表示,她赞同拉姆对现状的说明,但仍认为董事会应该做好准备,因为预计许可 PIR 捆绑请求的决定会被视为强制执行某些有关 IDN 捆绑和变体的持续流程的先例。麦克•西尔柏表示赞同苏珊的观点,并建议应清楚说明理由(即这样做不是为了开创先例),并且必须单独评估不同的情况。

      主席建议进行投票,董事会采取了以下行动:

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

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

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

      鉴于 2014 年 6 月 6 日,ICANN 转呈 PIR 的 RSEP 请求 request [PDF, 949 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.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

      此外,ICANN 在对所请求注册局服务展开技术评估时还咨询了 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 组织管理职能决策?

    2. 注册局服务评估政策属于 ICANN 共识性政策,自 2006 年 8 月 15 日起生效。依据该政策规定,RSTEP 报告已于 2014 年 7 月 29 日发布以 征询公众意见。公共评议期于 2014 年 8 月 13 日结束,未提交任何公众意见。此外,2014 年 6 月 10 日,ICANN 发布了 PIR 的 RSEP 请求以 征询公众意见。公众意见征询期于 2014 年 7 月 30 日结束,未提交任何公众意见。

    3. 未来 gTLD 申请轮次规划

      主席介绍了此议程事项,并就董事会在启动另一个新通用顶级域名项目申请轮次之前将如何以及是否启动研究和组织流程发起了对话。阿克兰•阿特拉表示,他希望确保有关此事项的任何决议都不是开放式的,而是拟定在启动另一个申请轮次之前需要开展的具体工作。里纳利亚•阿卜杜尔•拉希姆对阿克兰的看法表示认同,指出任何决议均应具体明确。

      希瑟•德莱顿表示,相关决议必须非常清楚地说明具体的行动方向,指出在启动另一个申请轮次之前必须采取的后续步骤。

      麦克•西尔柏对于在启动另一个 gTLD 申请轮次之前必须完成哪些工作表示了担忧,认为如果尚未设定此类日期并且直到完成先决工作后才能设定该日期,则决议的内容很可能并不明确。

      塞巴斯蒂安•巴肖莱对使用命名"第一轮"和"第二轮"来描述 gTLD 申请轮次提出质疑,认为这不符合 ICANN 组织的实际情况。史蒂夫•克罗克则表示,重新编写已经包含该命名的文档可能会引起混淆。布鲁斯•托金表示赞同塞巴斯蒂安的观点,指出在过去十四年中已经有了多个 gTLD 申请轮次,并建议按年份来命名轮次(例如,2000 年轮次、2004 年轮次和 2012 年轮次)。

      拉姆•莫汉表示,如果董事会将达成决议,这可能会被解释为董事会授权下一个申请轮次;同时,他对社群的潜在反应以及可能会产生董事会急于做出决定的印象表示担忧。拉姆指出,在启动下一个 gTLD 申请轮次之前,必须通过决议传达董事会希望完成的工作的重要性以及将进行的分析的深度。

      沃尔夫冈•科纳沃茨特对拉姆提出的担忧表示认同。之后,沃尔夫冈询问,是否估计了完成先决工作和启动下一个申请轮次的时间。阿克兰回应称,那取决于时间安排以及董事会确定需要在启动下一个轮次之前完成哪些工作。

      克里斯•迪斯佩恩对拉姆的担忧表示支持,并建议董事会目前暂不考虑此事项,而关注决议的措词,然后在 ICANN 第 51 届洛杉矶会议期间讨论该事项。阿克兰表示,社群对于审核流程的时间安排和程序一直存有各种疑问。

      董事会同意需要做出进一步考量,并将此事项推迟到 ICANN 第 51 届洛杉矶会议期间继续讨论。

      未达成任何决议。

    4. 2015 财年运营规划和预算

      乔治•萨多夫斯基提出决议并得到麦克•西尔柏的支持。

      谢林•查拉比介绍了此议程事项,并简要概述了经修订的 2015 财年运营规划和预算。于 2014 年 5 月 8 日发布以征询公众意见的 2015 财年运营规划和预算草案预计的收入为 $1.14 亿美元,运营成本为 $1.17 亿美元。关于其中的收入和运营成本,已经收到了大量意见。公共评议期结束后,董事会财务委员会 (BFC) 考虑了所有公众意见,研究了各种收入假设和敏感性分析,然后对预算进行了修改。经修订的 2015 财年运营规划和预算现在预计的收入为 $1.04 亿美元,运营成本为 $1.08 亿美元。谢林表示,为了实现减少上述数目的目标,BFC 逐一审核了每一项收入假设,CEO 和管理团队详细审核了运营成本并精简了人员招聘、差旅成本、专业服务、行政成本和资本支出。谢林还表示,为了努力降低成本,ICANN 第 51 届洛杉矶会议将不举办庆祝活动,因为此次会议没有当地主办机构赞助。

      埃里卡•曼询问建议减少哪些人员招聘。苏珊娜•贝内特做出回应,并解释称 2014 日历年度中将不招聘新人员,所有新人员招聘将推迟到 2015 年。苏珊娜进一步解释道,如有必要,可以遵照某些指导原则实施例外流程。谢林表示,这样做可以降低 2015 财年的成本,因为过去几年来,人员成本一直在不断增长。

      约恩内•索恩宁询问建议减少哪些差旅成本。苏珊娜做出回应,并解释称要求每一位全球领导团队成员将他们的差旅预算减少 10%,至于如何完成减少预算的目标,将由每个部门决定。

      约恩内还询问建议减少哪些专业服务。阿克兰做出回应,并解释称,例如,他所在的团队审核了自己的任务清单,在内部而不是外部决定了可以采取哪些措施,并确定了某些可以取消或推迟的事项。阿什文•兰根也做出回应,表示 IT 部门正设法利用各种资源来降低成本,同时不会对服务质量造成任何负面影响。克里斯•迪斯佩恩表示,他已经要求 BFC 采用专业服务来了解 ICANN 有哪些资本支出。

      贡萨洛•纳瓦罗对于董事会为什么关注降低成本而不是重新分配存款提出质疑。哈维尔•卡尔维兹和贡萨洛同意进一步就此主题展开讨论。

      随后,谢林向董事会宣读了所提决议。

      主席建议进行投票,董事会采取了以下行动:

      鉴于根据上一财年的众多社群商议以及全体 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 财年运营规划和预算中的陈述设立可变授权费(按每个注册商和每笔交易)。

      十四位董事会成员投票赞成第 2014.09.09.07 号决议。雷•普拉扎和布鲁斯•托金未能对该决议投票。决议通过。

      第 2014.09.09.07 号决议的理由

      根据《ICANN 章程》第 XVI 条第 4 款,董事会负责通过年度预算并将其发布到 ICANN 网站上。2014 年 5 月 8 日,ICANN 公布了 2015 财年运营规划和预算草案,以征询公众意见。这份草案是数月以来与管理团队的多次讨论,以及与 ICANN 支持组织、咨询委员会和其他利益相关方团体的多次协商的结果。考虑到干预活动和通过公众意见论坛接收到的意见,ICANN 对 2014 年 5 月 8 日公布的 2015 财年运营规划和预算草案进行了一些有限但重大的修订。

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

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

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

    5. ICANN 五年战略规划终稿(2016 财年 - 2020 财年)

      该议项已从议程中删除。

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

      塞巴斯蒂安•巴肖莱介绍了此议程事项,并简要概述了 2014 年 6 月在伦敦举办的第二届一般会员峰会 (ATLAS II)。董事会考虑了对决议文本的可能修订。麦克•西尔柏表示,他对在会议期间起草决议感到不满,但愿意继续讨论以确定董事会是否能够就该决议达成共识。麦克还指出,由于 ALAC 尚未表明 ATLAS II 宣言的哪一部分构成了建议,因此,董事会在建议尚未提交之时就讨论跟进 ALAC 建议明显为时过早。史蒂夫•克罗克同意麦克的看法,并表示决议应反映出董事会期待与 ALAC 召开会议来讨论该宣言。

      沃尔夫冈•科纳沃茨特表达了自己的观点,认为 ICANN 作为整体需要强大的一般会员活动和一般会员咨询委员会。为此,沃尔夫冈建议董事会应继续与 ALAC 合作,并将此流程推进到下一阶段,虽然后续步骤尚不明确。例如,后续步骤可能包括合并到 ICANN 公共会议中的其他峰会或地区峰会。ICANN 第 50 届会议期间的峰会不应成为此事项的终结点。沃尔夫冈询问是否应该就该宣言征询公众意见。

      塞巴斯蒂安表示,董事会需要做更多工作,而不仅仅是对 ALAC 所做的工作表示感谢;确切地说,董事会需要表明自己将跟进 ALAC 的工作,了解宣言中提出的意见,并考虑定期召开峰会的计划。主席表示会将接受 ALAC 的实际建议作为董事会与 ALAC 之间互动的机制。

      克里斯•迪斯佩恩表示,根据他的理解,ALAC 现在将采纳 ATLAS II 宣言,并确定通过建议或其他形式提交给董事会的内容。克里斯进一步指出,原则上,他不反对定期召开峰会,但对于现在就此事项做出任何指示是否合适表示质疑,因为目前尚未就该主题展开任何讨论。

      里纳利亚建议,董事会应表明它期待在洛杉矶就所提供的建议与 ALAC 或一般会员社群进行互动。克里斯表示,"建议"一词在章程中具有特殊含义,并且董事会未收到来自一般会员社群的建议,而是收到了来自 ALAC 的建议。

      奥尔加•马德鲁加–福蒂表示支持里纳利亚的看法。

      克里斯指出,董事会内部对于董事会是否要研究定期召开一般会员峰会的可能计划存在分歧。麦克表示,ATLAS II 宣言并未提及继续召开峰会,并对决议中为什么提到这一点提出质疑。比尔指出,董事会尚未讨论是否要研究定期召开一般会员峰会的可能计划,并建议在洛杉矶董事会会议之前中止讨论该决议,到时,董事会可以进行讨论并以某种形式通过决议。

      主席解释道,该决议旨在对 ALAC 所做的工作表示感谢,并赞同纳入建议定期召开峰会的内容有些过头;即使决议中未反映这一主题,也可以就此继续进行对话。董事会努力传达的谢意才是决议的主旨。

      史蒂夫•克罗克提出决议并得到乔治•萨多夫斯基的支持。

      主席建议进行投票,董事会采取了以下行动:

      鉴于第二届一般会员峰会 (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, 201 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 的活动。

      十一位董事会成员投票赞成第 2014.09.09.08、2014.09.09.09、2014.09.09.10 和 2014.09.09.11 号决议。法迪•切哈德、沃尔夫冈•科纳沃茨特和塞巴斯蒂安•巴肖莱弃权。雷•普拉扎和布鲁斯•托金未能对这些决议投票。决议通过。

      塞巴斯蒂安表示,他弃权是因为他支持决议中应包括提及"研究定期召开一般会员峰会的可能计划"的内容。沃尔夫冈弃权是因为他认为定期召开峰会符合 ATLAS II 宣言的精神,并支持应在决议中包括此项内容。法迪投弃权票的原因与沃尔夫冈相同。

      第 2014.09.09.08 - 2014.09.09.11 号决议的理由

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

      此文档源于在 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 社群的反馈。

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

    7. 其他事务

      拉姆•莫汉提出修改注册局服务评估小组 (RSEP) 和注册局服务技术评估小组 (RSTEP) 流程程序的问题。作为背景信息,拉姆解释称很多问题(包括注册局做出的语言更改)都可能会触发 RSEP,如果需要深入分析,则应将请求转呈 RSTEP,继而由董事会在 30 天(规定的时间范围)内做出审批。拉姆表示,如果每个新通用顶级域名轮次包括的 TLD 少于十个,则此流程将易于进行管理;但是,根据当前程序指导原则,包括 1,300 个新 TLD 的 2012 年轮次将增加 RSEP/RSTEP 流程的管理难度。有鉴于此,拉姆请求董事会要求工作人员审核并分析现有的 RSEP/RSTEP 流程,包括董事会对此流程的参与程度,并就如何简化该流程提供建议。作为说明,拉姆解释称他为某个注册局工作,该注册局已经向 ICANN 归档了几个 RSEP 和 RSTEP,因此他非常熟悉此流程的细节。此外,制定并作为共识性政策要求采用 RSEP/RSTEP 流程时,拉姆还是 GNSO 的成员。

      主席表示,制定 RSEP/RSTEP 流程时,在处理任何有关安全性和稳定性的事项时都相当谨慎;而且,出于谨慎考虑,董事会将负责监督此类请求的更改。主席表示赞同拉姆的看法,并建议工作人员提供一个建议的程序,在其中包括足够的技术深度并保证独立性,以便每项请求都会对哪些安全性和稳定性问题可能适用进行全面的调查研究。

      约恩内•索恩宁提出问题,询问 GNSO 应在修改 RSEP/RSTEP 流程的过程中发挥什么作用。总法律顾问兼秘书解释称,最初制定该程序是因为注册局很难添加新的注册局服务,而这会在注册局、GNSO 与 ICANN 董事会和工作人员之间造成冲突。到目前为止,当前的流程一直非常有用,但总法律顾问认为,如果新通用顶级域名超过一千个,将很难以相同的方式管理请求的更改。他表示,对该程序做出更改时应小心谨慎,并考虑相关流程的工作方式,以及在实施任何更改之前是否需要完成其他 GNSO 工作。

      阿克兰•阿特拉表示,工作人员将准备有关 RSEP/RSTEP 流程的建议,供 ICANN 第 51 届洛杉矶会议期间审核。

      未达成任何决议。

已于 2014 年 10 月 17 日发布

minutes-09sep14-zh.pdf  [272 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."