Skip to main content
Resources

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

本页面还提供其他语种:

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

当地时间 2016 年 5 月 15 日 14:45,ICANN 董事会在阿姆斯特丹召开了例行会议。

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

除主席外,以下董事也参加了全部或部分会议: 里纳利亚·阿卜杜尔·拉辛 (Rinalia Abdul Rahim)、阿克兰·阿特拉(Akram Atallah,总裁兼首席执行官)、谢林·查拉比(Cherine Chalaby,副主席)、罗恩·达席尔瓦 (Ron da Silva)、克里斯·狄思潘 (Chris Disspain)、阿莎·合美嘉妮 (Asha Hemrajani)、拉斐尔·利托·伊瓦拉 (Rafael Lito Ibarra)、马库斯·库墨 (Markus Kummer)、布鲁诺·朗万 (Bruno Lanvin)、埃里卡·曼 (Erika Mann)、乔治·萨多夫斯基 (George Sadowsky)、麦克·希尔伯 (Mike Silber)、布鲁斯·托金 (Bruce Tonkin)、露丝薇斯·范德朗 (Lousewies van der Laan) 以及吴国维。

以下董事会联络人参加了全部或部分会议: 拉姆·莫罕(Ram Mohan,SSAC 联络人)、琼尼·索尼能(Jonne Soininen,IETF 联络人)和苏珊·沃尔夫(Suzanne Woolf,RSSAC 联络人)。

以下董事会联络人因未能参加会议而表示歉意: 托马斯·施耐德(Thomas Schneider,GAC 联络人)。

观察员: 贝基·伯尔 (Becky Burr) 和马跃然 (Göran Marby)。

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

以下 ICANN 高级管理人员和工作人员参加了全部或部分会议: 苏珊娜·宾内特(Susanna Bennett,首席运营官)、米歇尔·布莱特(Michelle Bright,董事会支持内容经理)、邓肯·伯恩斯(Duncan Burns,全球传播副总裁)、哈维尔·卡尔维兹(Xavier Calvez,首席财务官)、戴维·康纳德(David Conrad,首席技术官)、莎莉·科斯特顿(Sally Costerton,总裁高级顾问兼全球多利益相关方合作事务高级副总裁)、艾伦·葛洛根(Allen Grogan,首席合同合规官)、塔瑞克·卡梅尔(Tarek Kamel,政府合作事务总裁高级顾问)、梅丽莎·金(Melissa King,董事会支持部副总裁)、温西安·科尼格斯菲尔德(Vinciane Koenigsfeld,董事会支持内容经理)、克里斯托弗·蒙蒂尼(Christopher Mondini,NA & GBE 利益相关方合作副总裁)、戴维·奥利佛(David Olive,政策制定支持部高级副总裁兼 ICANN 伊斯坦布尔地区总部总经理)、阿什文·兰根(Ashwin Rangan,首席创新与信息官)、艾米·斯塔索斯(Amy Stathos,副总法律顾问)以及特里莎·斯旺哈特(Theresa Swinehart,战略事务总裁高级顾问)。

以下是 2016 年 5 月 15 日 ICANN 董事会例行会议的记录。

  1. 认可议程:
    1. 批准董事会会议记录
    2. 安全与稳定咨询委员会 (SSAC) 任命
    3. GNSO gTLD 注册管理机构利益相关方组织章程修正案(2016 年)
    4. ICANN 会议期间的行为问题
    5. 董事会互联网治理工作组 (BWG-IG)
  2. 主要议程:
    1. 审议关于隐私和代理服务委任的 GNSO 政策建议
    2. 关于 .HOTEL 的报告
    3. 2017 财年 SO/AC 额外预算请求批准
    4. 2016 年 10 月 ICANN 会议会场签约
    5. USG IANA 管理权移交 — 其他 2016 财年开支和资金
    6. 其他事务
      1. 提高开放性和透明度 — 董事会审议
  3. 执行会议 — 保密

 

  1. 认可议程:

    主席介绍了认可议程中的事项并发起投票。董事会随后以口头表决的方式采取了以下行动:

    发布决议:批准本认可议程中的以下决议:

    1. 批准董事会会议记录

      第 2016.05.15.01 号决议:理事会批准 2016 年 3 月 3 日、9 日 和 10 日的 ICANN 董事会会议记录。

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

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

      鉴于 SSAC 成员资格委员会代表 SSAC 要求董事会任命约翰·莱文 (John R. Levine) 到 SSAC 任职,自董事会批准之日起即刻生效,至 2019 年 12 月 31 日止任期三年。

      兹此发布第 2016.05.15.02 号决议:董事会任命约翰·莱文到 SSAC 任职,即刻生效,至 2019 年 12 月 31 日任命结束,任期三年。

      第 2016.05.15.02 号决议的理由

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

      SSAC 能否作为合格的主体持续运营取决于同意自愿投入时间和精力来执行 SSAC 使命的优秀主题问题专家是否增加。约翰·莱文拥有广博的技术专业知识和敏捷的思辨能力,在技术界享有盛名。SSAC 深信约翰·莱文先生必将成为 SSAC 的重大贡献者,董事会同意 SSAC 推荐约翰·莱文进入 SSAC。

    3. GNSO gTLD 注册管理机构利益相关方组织章程修正案(2016 年)

      鉴于 ICANN 章程(第 X 条第 5.3 款)规定“每个 [GNSO] 利益相关方团体都应始终得到 ICANN 董事会的认可。”

      鉴于董事会已确立修订 GNSO 利益相关方团体和选区章程的流程(以下简称“流程”)。

      鉴于 GNSO gTLD 注册管理机构利益相关方团体 (RySG)、ICANN 工作人员、组织效率委员会 (OEC) 均已完成在流程中所确定的所有步骤。

      鉴于修订看似解决在先前董事会第 2015.10.22.14 号决议中董事会要求 RySG 注意的一些事务。

      兹此发布第 2016.05.15.03 号协议:ICANN 董事会批准 RySG 章程修订,并将其以简报文件形式提交至董事会。RySG 和 ICANN 工作人员应按照要求将修订的章程发布到相应的 RySG 网页上。董事会要求 RySG 在一年之内完成修订的审查工作,以确定这些修订能否达到预期影响。ICANN 工作人员还需进一步与 RySG 的领导团队分享此决议。

      第 2016.05.15.03 号决议的理由

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

      ICANN 章程(第 X 条第 5.3 款)规定“每个利益相关方团体都应始终得到 ICANN 董事会的认可。”董事会已将此解释为,通用名称支持组织 (GNSO) 中利益相关方团体 (SG) 和/或选区管理文件的任何修订,都要得到 ICANN 董事会正式批准。

      2013 年 9 月,董事会制定了修订 GNSO 利益相关方团体和选区章程的流程(以下简称“流程”),为达到 ICANN 章程要求提供了一个简便的方法。

      今年早些时候,GNSO 的 gTLD 注册管理机构利益相关方组织 (RySG) 批准了管理文件修正案并充分利用这一流程。

      考虑了哪些提案?

      利益相关方团体已修改了现有章程文件,以针对会员组成变化作出调整,更有效地履行其政策制定职责。在修正条款中,最大的章程变更在以下方面:

      • 创建新的“准”成员级别;
      • 更改加权投票类别和团体的衡量标准;以及
      • 调整社群费用结构,以容纳更多准会员。

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

      除在 RySG 内进行广泛的社群审议外,拟定修订案还接受了 43 天的公众意见征询(2016 年 2 月 22 日至 4 月 4 日)。公众意见征询期结束后,工作人员在 2016 年 4 月 15 日提交总结报告供社群和董事会审核。

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

      董事会审核了带红色修订标记的章程修正案提案以及工作人员针对社群意见撰写的总结报告的副本。

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

      GNSO 注册管理机构利益相关方团体、ICANN 工作人员、组织效率委员会均完成在流程中所确定的所有步骤。公布修正案以接受社群的审核与评议,结果表明修订得到支持。

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

      利益相关方团体已修改了现有章程文件,以针对会员组成变化作出调整,更有效地履行其政策制定职责。

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

      修订内容包括调整 RySG 费用结构,此举可能会影响社群个人会员。

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

      此决定预计不会对域名系统的安全性、稳定性与弹性造成任何影响。

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

      修正案提案接受 43 天的公众意见征询(2016 年 2 月 22 日至 4 月 4 日)。

    4. ICANN 会议期间的行为问题

      鉴于 ICANN55 召开期间及之后,有关某些社群成员在互动中的行为的问题在各场会议和各个清单中不断被提出。

      鉴于董事会治理委员会 (BGC) 已审核预期行为标准的表述的以保护领域众多公认标准为准绳的修订提案,且建议董事会授权发布修订版本以征询公众意见。

      鉴于 BGC 还建议董事会要求总裁兼首席执行官或其指定人在适当的时候聘用一位精通于起草和实施反骚扰政策的专家,协助制定在 ICANN 公共会议上应遵循的社群反骚扰政策/程序。

      兹此发布第 2016.05.15.04 号决议:董事会特此授权发布预期行为标准修订提案以征询公众意见。

      兹此发布第 2016.05.15.05 号决议:董事会特此要求总裁兼首席执行官或其指定人在适当的时候聘用一位精通于起草和实施反骚扰政策的专家,协助制定在 ICANN 公共会议上应遵循的社群反骚扰政策/程序,条款可能包括投诉处理、决议和执行流程等等。

      第 2016.05.15.04 – 2016.05.15.05 号决议的理由

      ICANN55 召开期间及之后,有关某些社群成员在互动中的行为的问题在各场会议和各个清单中不断被提出,董事会同意解决此问题。作为响应,董事会已确定并重申,ICANN 董事会和工作人员都以非常严肃的态度对待会议中的骚扰和其他不当行为。ICANN 和社群成员目标一致,确保 ICANN 社群成员能够为营造一个无歧视、无骚扰的环境严于律己。

      作为一个组织,ICANN 在此问题方面制定了完善的内部政策,包括对工作人员和董事会成员进行强制性培训。虽然与 ICANN 董事会和工作人员不同,ICANN 社群成员无需受制于上述政策和规章制度,但 ICANN 切实希望社群成员遵守特定的预期行为标准(以下简称“标准”)。这些标准目前的表述没有具体解决骚扰问题,但却提供了一套指导社群成员如何互动的高层次指南。正如董事会先前所承诺的,董事会治理委员会 (BGC) 的任务是考虑如何尽可能改善这些标准的表述。鉴于此,已提议根据众多公认的保护标准对标准进行修订,而且 BGC 已对修订进行审核并建议董事会授权发布标准修订提案以征询公众意见。

      与此同时,工作人员已展开与社群领导者的讨论,董事会和工作人员也收集到了来自社群各层关于制定社群反骚扰政策流程的建议。从目前收到的意见来看,社群成员(至少已公开评议的成员)希望 ICANN 在需要及适当时聘用专家以协助制定在 ICANN 公共会议上应遵循的社群反骚扰政策/程序,相应地亦会将此建议提供给社群以做进一步讨论和意见征集。此外,各社群领导者及成员,无论是作为该议题倡导团体中的一员还是个体身份,提供了许多具体例子,为政策/程序提议草案补充了信息。具体包括:

      1. Ada 倡议 (https://adainitiative.org/continue-our-work/ada-initiative-event-anti-harassment-policy/);
      2. IETF (https://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html);
      3. 互联网治理论坛 (http://www.intgovforum.org/cms/aboutigf/igf-code-of-conduct);
      4. NTEN(非盈利技术网络)http://www.nten.org/ntc/about-the-ntc/code-of-conduct/);
      5. RIPE (https://ripe72.ripe.net/on-site/code-of-conduct/);
      6. 联合国及其特殊机构的反骚扰行政政策(其中一些收集在 http://www.ficsa.org/component/sobipro/?task=download.file&fid=37.1329&sid=1266&Itemid=0 [DOC, 36 KB] 中)

      此外,GNSO 主席和副主席代表 GNSO 理事会致函,建议在制定社群反骚扰政策和程序时应予以全方位考量。信函副本详见 http://gnso.icann.org/en/correspondence/bladel-to-atallah-25apr16-en.pdf [PDF, 299 KB]。

      BGC 因此还建议,董事会应要求总裁兼首席执行官或其指定人在适当的时候聘用一位精通于起草和实施反骚扰政策的专家,协助制定在 ICANN 公共会议上应遵循的社群反骚扰政策/程序,条款可能包括投诉处理、决议和执行流程等等。董事会同意此种方式。

      此举将会给 ICANN 带来轻微的财政影响,预计不会超过已定预算额,而且这对域名系统的安全、稳定或弹性将不会产生任何影响。

      此项决议体现了组织管理职能,无需征询公众意见。

    5. 董事会互联网治理工作组 (BWG-IG)

      鉴于互联网治理格局持续不断地完善,ICANN 在互联网治理生态系统中的角色也将发生转变,而且董事会与互联网治理工作管理层之间加强对话也将让 ICANN 受益匪浅。

      鉴于董事会治理委员会 (BGC) 已建议董事会成立董事会互联网治理工作组 (BWG-IG),以在适当时对 ICANN 在其使命内及致力于其策略计划的、参与互联网治理工作相关的工作提供咨询和建议,包括与 ICANN 工作人员协商互联网治理活动的合作及参与事项。

      鉴于 BGC 已建议董事会任命以下董事会成员到 BV-WG 任职:里纳利亚·阿卜杜尔·拉辛 (Rinalia Abdul Rahim)、罗恩·达席尔瓦 (Ron da Silva)、克里斯·狄思潘 (Chris Disspain)、马库斯·库墨(Markus Kummer,主席)、埃里卡·曼 (Erika Mann)、乔治·萨多夫斯基 (George Sadowsky) 和露丝薇斯·范德朗 (Lousewies van der Laan)。

      兹发布第 2016.05.15.06 号决议:董事会特此批准按照 BGC 推荐的章程成立董事会互联网治理工作组 (BWG-IG),工作组包括以下成员:里纳利亚·阿卜杜尔·拉辛 (Rinalia Abdul Rahim)、罗恩·达席尔瓦 (Ron da Silva)、克里斯·狄思潘 (Chris Disspain)、马库斯·库墨(Markus Kummer,主席)、埃里卡·曼 (Erika Mann)、乔治·萨多夫斯基 (George Sadowsky) 和露丝薇斯·范德朗 (Lousewies van der Laan)。

      董事会出席会议的所有成员投票赞成第 2016.05.15.01、2016.05.15.02、2016.05.15.03、2016.05.15.04 - 2016.05.15.05 和 2016.05.15.06 号决议。决议通过。

  2. 主要议程:

    1. 审议关于隐私和代理服务委任的 GNSO 政策建议

      布鲁斯·托金介绍了议程项目,并向董事会提交了一份关于隐私和代理服务提供商委任的已被 GNSO 采纳的共识性政策建议之摘要。布鲁斯在其报告中指出,GAC 在其 2016 年 3 月发布的马拉喀什公报上向董事会提出了关于 GAC 需要更多时间考虑 GNSO 政策建议相关的潜在公共政策问题。

      董事会根据 GAC 的建议考虑了 GNSO 政策建议的后续工作。克里斯·狄思潘提到,政策制定流程让 GAC 可以参与其中,此外,GAC 也可以就公共政策问题提出意见。克里斯建议在赫尔辛基 ICANN 会议上,GAC 应与 GNSO 就此事务展开对话,如果 GAC 在对话后提出任何建议,董事会即可立即纳入考量。布鲁斯指出,在赫尔辛基会议期间可能会留一些时间让各方对话。

      布鲁斯·托金提出决议,并得到克里斯·狄思潘的支持。董事会采取了以下行动:

      鉴于 GNSO 理事会已于 2013 年 10 月 31 日批准 ICANN 董事会就 ICANN 委任隐私和代理域名注册服务提供商事宜提出的由工作组执行政策制定流程之章程,进一步说明详见 http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf [PDF, 463 KB]。

      鉴于 PDP 遵循了 ICANN 章程中所规定的 PDP 步骤,最终于 2015 年 12 月 8 日向 GNSO 理事会提交了《最终报告》。

      鉴于隐私和代理服务委任问题的 PDP 工作组 (WG) 对其所有最终建议已达成完全共识(见 http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf [PDF, 1.24 MB])。

      鉴于 GNSO 理事会审查讨论了隐私和代理服务委任问题的 PDP WG 的最终建议,并于 2016 年 1 月 21 日通过一致投票采纳了这些建议(请参考:http://gnso.icann.org/en/council/resolutions#201601)。

      鉴于 GNSO 理事会投票达到并超过了为 ICANN 缔约方增加新义务所需的投票门槛(亦即绝大多数票)。

      鉴于根据 ICANN 章程已向社群就批准的建议开放公共评议期,以在 ICANN 董事会作出决定之前给予社群合理的机会对采纳情况发表评议,并对征集到的意见进行了总结和报告(见 https://www.icann.org/en/system/files/files/report-comments-ppsai-recommendations-31mar16-en.pdf [PDF, 299 KB])。

      鉴于 ICANN 章程最终规定,董事会应就关于“凡是董事会正在考虑予以采用且对互联网或第三方运营有重大影响的政策,其中包括强制收取任何费用”及“适当考虑及时提出的任何建议”征询意见。

      鉴于董事会已通知 GAC,发布 GNSO 最终建议以于 2016 年 2 月 19 日开放公众意见征询(见 https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2 [PDF, 819 KB])。

      鉴于 GAC 在其 2016 年 3 月 9 日公布的马拉喀什公报中建议 ICANN 董事会,GAC 需要更多时间考虑关于采用最终 PDP 建议方面的潜在公共政策问题,并指出 2016 年 6 月召开的 ICANN56 会议将是考虑这些事项的良机(见 https://gacweb.icann.org/download/attachments/28278854/GAC%20Morocco%2055%20Communique%20FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 [PDF, 567 KB])。

      兹此发布第 2016.05.15.07 号决议:董事会感谢 GNSO 按照其要求完成政策制定流程 (PDP),并确认收到 PDP 最终报告以及 GNSO 理事会关于最终 PDP 建议的建议报告。

      兹此发布第 2016.05.15.08 号决议:董事会确认需要更多时间考虑最终 PDP 建议,包括条款制定和考虑 GAC 建议的时间,若有将提供。董事会在芬兰赫尔辛基 ICANN56 公共会议后的首次董事会会议上对建议采取进一步行动。

      出席会议的所有董事会成员一致投票赞成第 2016.05.15.07 – 2016.05.15.08 号决议。决议通过。

      第 2016.05.15.07 – 2016.05.15.08 号决议的理由

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

      2011 年 10 月,董事会就新结构形式的注册服务机构认证协议 (RAA) 与注册服务机构利益相关方团体展开协商,ICANN 董事会同时还要求 GNSO 提交一份问题报告以启动解决 RAA 中未解决的遗留问题的 GNSO PDP。2013 年 6 月,ICANN 董事会批准了新的 2013 版 RAA,并将委任隐私和代理服务这一议题确定为通过 GNSO PDP 解决的唯一问题。WHOIS 审核小组在其 2012 年 5 月发布的最终报告中也提到该议题,其中审核小组强调说,这些服务当前缺乏透明和统一规则,导致利益相关方面临无法预料的后果。审核小组认为适当监管此类服务可解决利益相关方的需求和问题,并建议 ICANN 考虑委任体系。在委任计划出台前,仅由于 2017 年 1 月 1 日失效的 2013 RAA 暂行规范在某些方面提供此类服务,或由 ICANN 实施委任计划,以先到者为准。

      GNSO 理事会在其 2016 年 1 月 21 日会议上批准了 PDP 工作组于 2015 年 12 月 8 日提交的最终报告中的所有最终建议,理事会在 2016 年 2 月向董事会提交的关于此议题的建议报告亦获批准。根据 ICANN 章程,开放了公共评议期,以促进关于采纳建议的公众意见征询。公众意见征询期截止于 2016 年 3 月 16 日。如 ICANN 章程附录 A 中所述,PDP 建议正交送董事会予以审查和决议。

      正在考虑的提案是什么?

      GNSO 政策建议包括:最大程度降低隐私和代理服务运营的强制性要求;维护滥用报告指定联系点及发布委任提供商名录;处理应特定第三方请求披露和/或发布客户联络人详细信息请求相关的要求;关于披露和发布此类详细信息以及拒绝披露或发布的条件;以及取消委任服务提供商管理原则。最终建议的完整列表和范围,详见 GNSO 理事会提交至董事会的建议报告的附录 A(见 http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-en.pdf [PDF, 491 KB])。

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

      按照 GNSO PDP 手册规定,在 PDP 早期阶段,工作组联系了所有 GNSO 利益相关方团体和选区以及其他 ICANN 支持组织和咨询委员会以征集他们的意见。在此 PDP 的有效期间内的所有 ICANN 公共会议上,工作组还召开了多次社群公开会议。工作组还向 ICANN 注册服务机构服务部和合规小组征询了关于潜在的实施问题的意见。在筹备 PDP 之前,开放了初步问题报告、工作组初步报告以及 GNSO 理事会采纳工作组最终报告的公共评议期。最终建议的形成基于工作组对所收集到的关于初步报告的公众意见和反馈信息的审查和权衡,具体内容详见《最终报告》。

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

      工作组收集到大量关于区分用作非商业目的域名的域名注册人与执行网上金融交易注册人之可行性的公众意见。这曾一度是工作组初步报告中的一个开放性问题,因为当时许多工作组成员都支持进行区分。工作组在审查了收到的公众意见后又做进一步审议,并最终就建议达成共识,即出于委任服务之目的不做此类区分。

      此外,社群还表达了对以下需求的关注:确保有完善的预防措施维护客户数据隐私,以及在合法获取信息(如,应执法部门和知识产权持有人之请求)与保护隐私之间保持平衡。针对工作组初步报告收到的众多公众意见也强调了无缘由披露隐私信息存在的潜在危险,其中包括对域名注册人某些团体及隐私/代理客户的人身安全带来的威胁。工作组最终建议包括许多建议的原则和政策,旨在提供比现行关于隐私和代理服务、第三方请求获取客户信息以及与处理客户通知、信息请求和域名转让等此类议题相关的域名注册人相关的原则和政策更加具体化的原则和政策。

      工作组还收到一些建议,指出提交和处理应执法部门包括 GAC 公共安全工作组之要求披露保密信息均缺乏一个详尽的框架。在初步报告中,工作组就是否需要以及如何制定框架问题征询了社群意见,此外,还对一些更加具体的问题征询意见,比如是否应强制委任的提供商遵从其管辖区执法部门明确提出的不通知客户的请求。根据收到的意见,工作组同意隐私和代理服务提供商应遵从执法部门明确提出的不通知客户(如适用法律要求这样做)的请求。提供商可自愿采用更为严格的标准,或是配合执法部门。由于工作组未收到关于如何制定出适用于执法请求的特定框架的具体提案,因此其最终报告中包括一项针对某些最低要求的建议,如果将来制定框架,则可能将其纳入其中。

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

      董事会审核了 PDP 工作组的最终报告、GNSO 理事会向其提交的议题的建议报告、针对 GNSO 理事会采纳最终报告中的建议开放公共评议期后收集到的公众意见小结以及自 GAC 收集到的议题建议。

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

      建议根据 ICANN 章程附录 A 中所述的 GNSO 政策制定流程提出,并且已获得 GNSO 理事会的一致支持。如 ICANN 章程所述,理事会绝大多数的支持促使董事会必须采纳建议,除非有超过三分之二的董事会成员投票表示该建议的政策并不符合 ICANN 社群或 ICANN 的最佳利益。

      章程还允许就董事会采纳提议的政策后可能会引起的公共政策问题征询 GAC 的意见。GAC 已指出,采纳这些政策建议可能会引起一些公共政策问题,鉴于此情况,董事会有责任考虑 GAC 可能就该议题及时提供的任何建议。因此,对于董事会来说,在 2016 年 3 月份的公报中明确给予 GAC 宽限的时间提供建议实为明智之举。

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

      制定一个完善的隐私和代理服务提供商认证项目将需笼络众多资源,且更需一个漫长的历程。推迟采用 PDP 建议,也将意味着延长 2013 RAA 暂行规范当前的到期日期将变得更为迫在眉睫。

      目前,隐私和代理服务委任计划空缺,而且对于此类服务的条款亦缺乏达成一致的社群制定的最佳实践。此 PDP 尝试为由 ICANN 制定的代理/隐私委任框架的制定和实施奠定良好基础。这是 ICANN 改善 WHOIS 系统的现行工作的一部分,其中包括实施 WHOIS 审核小组先前制定的实施建议。实施多项 GNSO 建议将会为隐私和代理服务在多个方面创建更为统一的一套标准,包括处理、执行或决定委任提供商第三方请求更为一致的程序,可在此程序中纳入保护消费者隐私的合理保护措施。

      然而,正如上述强调的,实施 PDP 的全部建议将会耗费大量的时间和资源,这不仅涉及到项目的规模,而且不容忽视的是,这是 ICANN 首次为此行业领域实施此类计划。尽管 RAA 对于该项目具有一定的参考作用,但工作组最终报告指出,从诸多因素来看,此模式可能并非最合适。

      工作组的最终报告还指出,在一些领域可能需额外的工作,这将会增加社群近期的工作量。例如,在对注册服务机构域名转让政策的下一轮审核中可能需解决域名转让背景下的隐私和代理服务问题。某种程度上即使 GAC 及时向董事会提供关于公共政策的建议,并且董事会接受了此建议,可能还是需要考虑针对执法部门和其他第三方的披露框架制定问题,或许还需与整体委任计划并行实施。

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

      如果 ICANN 采纳 PDP 关于创建新的委任计划的建议,尤其在隐私和代理服务提供商这一块,无论是最近还是将来,均有可能对 ICANN 带来财政影响。尽管如此,由于 RAA 中适用于此类服务的当前暂行规范于 2017 年 1 月 1 日到期,将需考虑是延长其有效期限(例如,若采用 PDP 建议则允许实施),还是在不采用 PDP 建议的情况下修订和更新规范。

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

      实施 PDP 建议不会直接导致与 DNS 相关的安全性、稳定性或灵活性问题。尽管委任隐私和代理服务提供商是 ICANN 改善 WHOIS 系统整体战略的一部分,但这不会影响或更变 WHOIS 协议(包括推出新的 RDAP,即注册数据访问协议)或 WHOIS 系统的当前功能。工作组制定其最终建议建立在对以下情况的良好认知之上,工作组明白,实施建议应考虑到超出本 PDP 范围之外的对 WHOIS 系统的任何其他政策或技术更改。

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

      存在争议的建议是定义 GNSO 政策制定流程的结果。对此类延迟行动不需要征询公众意见。

    2. 关于.HOTEL 的报告

      拉姆·莫罕指出自己存在潜在冲突,故弃权。艾米·斯塔索斯向董事会报告了于 2016 年 3 月 10 日针对 .HOTEL 和 .ECO IRP 宣言采取行动的跟进情况。在 2016 年 3 月 10 日的议程中,董事会指示总裁兼首席执行官尽早完成对 Despegar Online SRL、Donuts Inc.、Famous Four Media Limited、Fegistry LLC 和 Radix FZC(统称“.HOTEL 申诉人”)指称的门户网站配置问题的调查,并在完成调查后向董事会提交报告以供考量。艾米提醒董事会,IRP 中引起的关于配置错误的门户网站问题影响了新通用顶级域申请人和 GDD 门户网站,即只要门户网站用户执行特定类型的高级搜索,即可查看属于其他申请人的保密信息。

      艾米报告称,ICANN 的调查揭露的信息表明,由于错误配置问题,有限数量的特殊用户可访问并下载属于其他大多数用户的资料。艾米向董事会通报到,作为调查的一部分,工作人员最近向相关方发出了一系列信函,以收集有助于完成调查的其他证据,信函内容详见 ICANN 网站。

      埃里卡·曼询问,调查是否表明可访问什么数据以及工作人员是否收到了其信函的回应。艾米指出,已收到部分回应,并会将此类信息体现在调查的最终报告中。委员会决定根据调查的结论进一步讨论这一事项。

    3. 2017 财年 SO/AC 额外预算请求批准

      阿莎·合美嘉妮向董事会介绍了此议程事项。她解释道,各支持组织 (SO) 和咨询委员会 (AC) 已提交了 2017 财年额外预算请求。谢林·查拉比和阿莎向董事会汇报了关于考虑额外预算请求的流程,并解释了各部门的工作人员如何评估请求以及如何向财务委员会提供建议。

      利托·伊瓦拉、乔治·萨多夫斯基和克里斯·狄思潘询问了关于考虑和批准额外预算请求流程的问题。哈维尔·卡尔维兹针对通常通过额外预算请求流程请求的项目类型提供了一些示例,比如例外计划或支持组织和咨询委员会试行计划。哈维尔指出,有时候这些项目后来在 ICANN 的核心预算内完成。

      阿克兰·阿特拉提供了关于如何实现额外预算请求流程的背景信息,并强调该流程为 ICANN 能更好地对财务负责另辟蹊径。

      露丝薇斯·范德朗询问了关于流程工作人员在接受或拒绝请求前的准备情况。哈维尔指出,流程需占用大量的时间,戴维·奥利佛进一步作出解释,流程包括指导原则,以便社群明白提供资金的决定并非肆意而为。

      经过讨论后,董事会以口头表决的方式采取了以下行动:

      鉴于社群成员和 ICANN 工作人员在之前的讨论中认为有必要对 ICANN 支持组织 (SO) 和咨询委员会 (AC) 提出的额外预算请求的资金问题提前做出决定。

      鉴于工作人员已建立 SO/AC 额外预算请求流程,以收集、审核来自 SO 和 AC 的资金请求,并提交给董事会批准。

      鉴于 ICANN 社群在最终期限前提交了请求,并且这些请求已由代表政策、利益相关方参与和财务部门的工作人员小组进行了审核。

      鉴于审查小组建议批准的请求金额上限为 643,700 美元。

      鉴于董事会财务委员会已审核所遵循的流程以及工作人员的建议,并建议董事会批准工作人员的建议。

      兹此发布第 2016.05.15.09 号决议:董事会批准在 2017 财年将 643,700 美元的资金用于支付与采纳的 SO/AC 额外预算请求有关的费用。

      出席会议的所有董事会成员一致投票赞成第 2016.05.15.09 号决议。决议通过。

      第 2016.05.15.09 号决议的理由

      在今年早些时候批准预算对已确立的预算批准流程和时间表而言属合理安排,促进 ICANN 社群和 ICANN 工作人员的工作,并且不会产生额外费用。此项决议承诺投入的资金非常小,因此不需要为各项请求特别确定和批准资金来源。

      此决定预计不会对域名系统的安全性、稳定性与弹性造成任何影响。

      批准流程属于组织管理流程,在此之前已征求过社群的重要意见。

    4. 2016 年 10 月 ICANN 会议会场签约

      尼克·托马索 (Nick Tomasso) 与董事会讨论了关于计划于 2016 年 10 月在波多黎各圣胡安召开的 ICANN 会议。尼克提醒董事会,今年早些时候,考虑到寨卡病毒的威胁,ICANN 已决定将 ICANN 56 的会址从巴拿马共和国迁至芬兰赫尔辛基。他指出,ICANN 会议小组一直持续关注寨卡病毒的传播情况,这关系到即将到来的 ICANN 会议安全,经过与 SO/AC 领导者多轮的艰难讨论和协商,才得以为 2016 年 10 月的会议迁址。

      莎莉·科斯特顿告知董事会,高管团队经过艰难协商最终达成一致建议,同意推迟前往波多黎各,并表示慎重对待来自 SO/AC 领导以及群体其他成员的任何反馈意见。利托·伊瓦拉指出,来自拉丁美洲和加勒比海的许多群体表示,对于可能将 ICANN 年度大会从波多黎各迁移感到失望。

      董事会对关于 ICANN 57 迁移会址的可能性问题进行了讨论。麦克·希尔伯要求工作人员解释建议的基本原因,董事会讨论集中在与寨卡病毒相关的健康风险,以及会议地址仍为波多黎各亦或迁至其他地方对社群和财政带来的影响。尼克报告了可能的备选会场和日期,并向董事会明确表示,根据原定日期寻找备选会场不容乐观,因为十月到十一月初是一年中世界各地会议的高峰期,而且 ICANN 会议需在较长的时间内占用大量的会议空间。

      董事会的讨论也集中在董事会在选择会址的决策过程中所扮演的适当角色上,露丝薇斯·范德朗询问了董事会处理该事务的过程。讨论指出,工作人员的角色是选择会议的场地和位置,而董事会的角色是考虑是否批准超过 500,000 美元的支出的聘用流程的一部分。克里斯·狄思潘和谢林·查拉比指出,董事会财务委员会审核了提议的依据聘用流程额外支出资金的提议。董事会审核了更换会议地址所带来的财务影响,并且董事会成员对更换场地相关的开支进行了分析。

      董事会成员就是否应更换会址以及更换到什么时间和场地较为合适(如果更换)等问题各抒己见。董事会成员还要求工作人员,如果会议需要更换地址,则应制定更为明确的备用会址选择流程,包括关于如何保持在各地区轮流召开会议的标准,以及更换会址时或如果更换会址应考虑的因素。

      拉姆·莫罕提出此决议并得到马库斯·库墨的支持。董事会采取了以下行动:

      鉴于 ICANN 拟将 2016 年第三场公共会议的地点选在北美地区的波多黎各圣胡安。

      鉴于波多黎各寨卡病毒的爆发已导致需更换公共会议的地址。

      鉴于 ICANN 必须确定备选会场。

      兹此发布第 2016.05.15.10 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进 ICANN 57 相关的所有必要的合同签订和费用支付工作,总金额不超过 [协商一致后确定]。

      兹此发布第 2016.05.15.11 号决议:出于协商目的,该决议中的具体条款应按照《ICANN 章程》第 III 条第 5.2 款的规定进行保密,保密期截至总裁兼首席执行官认为可以发布保密信息为止。

      出席会议的十三位董事会成员一致投票赞成第 2016.05.15.10 – 2016.05.15.11 号决议。布鲁诺·朗万和露丝薇斯·范德朗投弃权票。决议通过。会议之后,里纳利亚·阿卜杜尔·拉辛向秘书长表示,她希望对第 2016.05.15.10 – 2016.05.15.11 号决议投弃权票,并对支持此项决议表达不满,她认为该决议尚未就会场选择流程以及选定地点的确定性提供进一步信息。

      第 2016.05.15.10 – 2016.05.15.11 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,目前 ICANN 每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。原定计划于 2016 年 10 月 29 日到 2016 年 11 月 4 日召开的第 57 届 ICANN 会议,将在北美地理区域内举行。原定会址为波多黎各圣胡安。由于寨卡病毒的爆发,导致 ICANN 2016 年会议不宜在原定会址召开,工作人员负责在世界各地区寻找适合的备选会场,即使必须更改原定日期仍需执行。

      根据流程,工作人员将对会议设施进行全方位分析以确保会场满足会议选择标准(见 http://meetings.icann.org/location-selection-criteria),确保为 ICANN 57 确定的备选地址适当。

      主办会议并提供必要的差旅补助会对 ICANN 产生财务影响,承担会议差旅成本也会给社群带来财务影响。但是,无论会议的举办地点和会场在何处,都必须面临这些影响。此项行动不会对 DNS 的安全性或稳定性造成任何影响。

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

    5. USG IANA 管理权移交 — 其他 2016 财年开支和资金

      谢林·查拉比介绍了此议程事项。他向董事会介绍,董事会财务委员建议批准 540 万美元的建议,以支付 2016 年 4 月 1 日至 2016 年 6 月 30 日这一期间 IANA 管理权移交的费用。谢林提供了关于移交开支的背景信息,指出董事会先前已批准 2016 财年运营规划和预算,其中包括移交开支。他还提到,建议的开支由项目成本支持团队制定,其中分析了自移交最初至财政年度结束期间估计所需的金额。

      谢林·查拉比提出此决议并得到埃里卡·曼的支持。董事会采取了以下行动:

      鉴于董事会已批准开支预算总额以支持 2015 财年和 2016 财年的 IANA 管理权移交项目(简称“项目”),以及所有经批准的预算总额将在 ICANN 第 55 届马拉喀什会议后用完。

      鉴于项目成本支持团队已投入工作,以制定项目在 2016 财年余下时间和 2017 财年的项目开支预算。

      鉴于项目成本支持团队已预估在 2016 财年余下时间的项目开支约高达 540 万美元。

      鉴于董事会财务委员会在 2016 年 3 月 3 日召开会议并批准向董事会建议批准最高 540 万美元的额外项目开支预算总额,以支付 2016 财年余下时间产生的项目开支。

      兹此发布第 2016.05.15.12 号决议:董事会批准最高 540 万美元的预算总额,以支付 2016 财年余下时间产生的项目成本,并且该费用将由储备金提供资金。

      出席会议的所有董事会成员一致投票赞成第 2016.05.15.12 号决议。决议通过。

      第 2016.05.15.12 号决议的理由

      IANA 管理权移交是一项重大举措,ICANN 社群的全体成员都为其花费了大量时间和资源。ICANN 支持社群成功完成项目(包括 USG IANA 管理权移交提案的编制和加强 ICANN 问责制跨社群工作组的工作)以及支持 ICANN 的实施计划工作对 ICANN 而言至关重要。

      考虑到其特殊性和预计产生的大量费用,此项目的资金不应从运营资金中拨款。因此,当董事会批准 2015 和 2016 财年运营规划和预算时,要求从储备金中拨出相应资金用于支付预计的移交计划费用。

      董事会之前批准了 2016 财年运营规划和预算,其中预计,由储备金提供资金的 USG IANA 管理权移交(“项目”)的预算总额为 700 万美元。由于项目在 2015 年 11 月底之前已用完此全部预算总额,董事会在 2016 年 2 月 2 日批准了 450 万美元的额外资金,以使项目在整个 ICANN 第 55 届马拉喀什会议期间不会缺乏资金。在 ICANN55 马拉喀什会议上,董事会于 2016 年 2 月 2 日批准了 150 万美元的额外资金,用于在 PCST 团队着手 2016 财年预算前的这一阶段为项目提供资金。

      董事会重申其于 2015 年 6 月 25 日发表的声明,即董事会“继续致力于支持社群获得所需建议,以制定支持移交流程的建议,又指出确保 ICANN 负责任和有效地使用社群托付资金的重要性。鼓励继续对独立顾问的未来工作采取成本控制措施。”(参见 https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c。)

      由于预期会继续开展有关项目问责制流程的社群工作,在 2016 财年的余下时间和 2017 财年内预期还会有更多开支。项目其他部分的实施规划工作也将继续开展。单独而言,为与社群合作改进此类项目开支的透明性和可控性,已成立项目成本支持团队负责为日后的工作制定成本预算。

      董事会财务委员会已决定,董事会需要批准大约 540 万美元的额外预算总额,以便 ICANN 支付 2016 财年余下时间产生的额外项目开支。

      由于此举措的开支和资金均经过董事会批准,ICANN 董事会现需批准 540 万美元的预算总额(由储备金提供资金),以作为 2016 财年余下时间的额外开销预算总额。

      该行动不会对域名系统的安全、稳定和弹性产生直接影响。

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

    6. 其他事务

      1. 提高开放性和透明度 — 董事会审议

        主席发起对任何其他事务的讨论,并介绍了董事会采取其他措施以加强开放性和透明度相关的议程项目,因为该项目与董事会会议审议相关。主席指出,此举也有可能支持 ICANN 社群加强 ICANN 问责制,因为这将减少诸如董事会如何以及为何做出决定的疑问。

        董事会成员提议编辑决议提案和理由,然后通过口头表决采取了以下行动:

        鉴于董事会相信提高对董事会审议的可获取性至关重要,增加开放度是致力于该目标的一种重要方式。

        鉴于 ICANN 董事会在其阿姆斯特丹研讨会上讨论了如何改善其职能,并认同提高对董事会审议和决策制定流程的可见性是使其更具担当、更加透明的一个重要部分。

        鉴于董事会指出社群呼吁增加开放性和透明度。

        鉴于董事会认为公开发布审议会议的文本和/或录音是提高开放性积极向前迈开的第一步,此类信息或对话不再受保密或特权限制。

        兹此发布第 2016.05.15.13 号决议:董事会指示总裁兼首席执行官或其指定人员协同董事会针对发布董事会审议会议的文本和/或录音制定提议计划,计划包括评估可能产生的资源成本及财务影响,以及草案流程,旨在:(i) 确保文本的准确性;以及 (ii) 修订部分的文本仍应保持机密或专有。

        兹此发布第 2016.05.15.14 号决议:董事会预期在赫尔辛基评估上述计划,如果计划令人满意,将在赫尔辛基会议后尽快开始测试关于发布董事会审议会议的文本和/或录音的提议流程。

        出席会议的所有董事会成员一致投票赞成第 2016.05.15.13 – 2016.05.15.14 号决议。决议通过。

        第 2016.05.15.13 – 2016.05.15.14 号决议的理由

        为了支持持续改进董事会审议和流程的可见性,董事会已决定在适当的情况下开放董事会审议会议的文本或录音。此提高开放性之举也有可能支持 ICANN 社群加强 ICANN 问责制,因为这将减少诸如董事会如何以及为何做出决定的疑问。该决定还直接为 ICANN 之前的工作及持续秉承决策公开、透明的运作目标提供了支撑。此外,ICANN 还始终以 ICANN 章程为准绳,正如 ICANN 章程第 III 条第 1 款所述,“ICANN 及其选区机构的运作方式应最大程度地体现公开性和透明性,并应与那些为确保公正性而设计的程序保持一致。”(ICANN 章程详见 https://www.icann.org/resources/pages/governance/bylaws-en - III。)

        在提交董事会之前将会有一些需要保密的问题,并且可能需要修改部分内容或拒绝提供完整文本,因此社群和董事会了解将如何采取这些决定非常重要。鉴于此,董事会正在指导制定一项包括提议流程在内的计划,他们将通过这些流程做出保密和专有内容的修改决定。应尽快制定此计划,以供董事会在 ICANN56 赫尔辛基会议上进行考量。

        该决定将不会对 DNS 的安全性、稳定性或灵活性产生任何影响。实施该项决定可能会导致成本增加,包括给 ICANN 带来的风险和财务影响。

        此决定属于一项组织管理职能,无需征询公众意见,不过视计划而定在随后某时间可能需征询公众意见。

  3. 执行会议 — 保密

    董事会主持召开了一场机密会议,内容涉及雇佣事宜。

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