Skip to main content
Resources

批准的董事会决议 | ICANN 董事会例行会议

本页面还提供其他语种:

  1. 认可议程:
    1. 批准董事会会议记录
    2. 任命 SSAC 的新成员
    3. 将 .LS(莱索托)顶级域转让给莱索托网络信息中心 (LSNIC)
    4. 2020 年 3 月 ICANN 会议会场签约
    5. 2020 年 6 月 ICANN 会议会场签约
    6. 2020 年 10 月 ICANN 会议会场签约
    7. 考虑来自 SSAC 建议文件 SAC047、SAC058、SAC061、SAC090 和 SAC097 的建议
    8. 一般会员组织审核 — 最终报告和建议
    9. 感谢第 62 届 ICANN 会议的当地主办机构
    10. 感谢第 62 届 ICANN 会议的赞助商
    11. 感谢第 62 届 ICANN 会议的口译员、工作人员以及会议和酒店团队
  2. 主要议程:
    1. 对重审请求 18-3 的考量:Astutium Ltd.
    2. 对重审请求 18-1 的考量:DotMusic Limited
    3. 对重审请求 18-2 的考量:dotgay LLC
    4. 其他事务

 

  1. 认可议程:

    1. 批准董事会会议记录

      第 2018.06.23.01 号决议:董事会批准 ICANN 董事会 5 月 3 日、5 月 17 日和 5 月 30 日特殊会议以及 ICANN 董事会 5 月 13 日例行会议的会议记录。

    2. 任命 SSAC 的新成员

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

      鉴于 SSAC 成员资格委员会代表 SSAC 要求董事会任命蒂莫西·阿普里尔 (Timothy April) 到 SSAC 任职,任期自董事会批准之日起即刻生效,至 2020 年 12 月 31 日止。

      兹此发布第 2018.06.23.02 号决议:董事会任命蒂莫西·阿普里尔到 SSAC 任职,任期自董事会批准之日起即刻生效,至 2020 年 12 月 31 日止。

      第 2018.06.23.02 号决议的理由

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

      SSAC 能否作为合格的主体持续运营取决于同意自愿投入时间和精力来执行 SSAC 使命的优秀主题问题专家是否增加。

      自 2011 年 8 月以来,蒂姆 (Tim) 一直担任 Akamai Technologies Inc. 信息安全部的高级架构师,他之前有过一些教育和研究方面的经验。他可以为 SSAC 带来的专业知识和技能包括内容分发网络设计、开发和运营以及 DDoS 和恶意软件分析、检测及抑制。蒂莫西还拥有以下方面的经验:大规模(权威和递归)域名服务器设计、开发和运营;协议设计和实施;以及一般安全审核经验。这些都可以作为 SSAC 内部现有技术和经验的补充。SSAC 相信蒂莫西·阿普里尔会为本组织作出卓越贡献。

      该决议属于组织管理职能,无需征询公众意见。SSAC 成员的任命符合公共利益,有助于推进 ICANN 使命的履行,因为它有助于 ICANN 组织实现加强 DNS 安全、稳定与弹性的承诺。

    3. 将 .LS(莱索托)顶级域转让给莱索托网络信息中心 (LSNIC)

      第 2018.06.23.03 号决议:在行使与 ICANN 签订的《IANA 域名职能合同》规定的责任时,PTI 审核并评估了将 .LS 国家和地区顶级域转让给莱索托网络信息中心 (LSNIC) 的请求。相关文件证明,在评估该请求时遵循了适当的程序。

      第 2018.06.23.03 号决议的理由

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

      根据《IANA 域名职能合同》的要求,PTI 已评估一项 ccTLD 转让申请,且目前正向董事会提交报告供其审核。提请董事会审核的目的是确保严格遵守相应流程。

      正在考虑的提案是什么?

      提案计划批准国家和地区顶级域 .LS 的转让申请,并向莱索托网络信息中心 (LSNIC) 授予经理人角色。

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

      在评估此转让申请的过程中,PTI 咨询了申请人和其他重要利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其在本地互联网社群中的影响力。

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

      PTI 未收到社群就此申请提出的重大问题或疑虑。

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

      董事会审核了以下评估:

      • 该域名具备转让资格,因为供考量的字符串代表已列入 ISO 3166-1 标准的莱索托;
      • 已咨询过相关政府的意见,且政府并无异议;
      • 提议的经理人及其联系人同意承担管理该域名的职责;
      • 提案体现了重要利益相关方的适当协商和支持;
      • 提案与任何已知法律或法规不抵触;
      • 提案确保了该域名在该国本地管理,并受当地法律约束;
      • 提议的经理人已确认,他们将以公平、公正的方式管理该域名;
      • 提议的经理人已证明拥有运营该域名所需的适当运营和技术能力、计划;
      • 提议的技术配置符合技术合规要求;
      • 未发现关于互联网稳定性的具体风险或顾虑;以及
      • 工作人员已建议根据考虑的各方面因素实施该申请。

      这些评估响应了适当的标准和政策框架,例如《域名系统结构和授权》(RFC 1591) 以及《国家和地区顶级域授权和管理的 GAC 原则与指导方针》。

      其他域名授权和转让报告请访问 http://www.iana.org/reports

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

      董事会未发现此申请存在任何特定隐患。

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

      及时批准符合各种公众利益标准的国家和地区域名管理机构对 ICANN 的整体工作会有积极影响,对此类国家和地区顶级域所服务的当地社群也会有积极作用,同时还可体现积极履行 IANA 域名职能合同中所述的职责。

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

      管理 DNS 根区中的国家和地区代码授权是 IANA 的职责,授权行动不会对预先计划的开支有任何重大影响。评估国家和地区顶级域在特定国家或地区内部所产生的财务影响并不是 ICANN 的职责。

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

      ICANN 认为此申请不会对安全、稳定或弹性造成明显不利影响。

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

      符合 ICANN 的使命并服务于全球公共利益

      这项行动支持 ICANN 所有部分问责制的有效性和持续改进,它符合 ICANN 的使命并服务于全球公共利益。

    4. 2020 年 3 月 ICANN 会议会场签约

      鉴于 ICANN 计划在拉丁美洲/加勒比地区召开 2020 年的第一场公共会议。

      鉴于 ICANN 组织已完成了对拉丁美洲/加勒比地区拟议会场的全面审核,认为位于墨西哥坎昆市的一个会场最为合适。

      兹此发布第 2018.06.23.04 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进与 2020 年 3 月在墨西哥坎昆市举办的 ICANN 公共会议会场相关的所有必要的合同签订和费用支付工作,总金额不超过 [协商一致后确定的金额]。

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

      第 2018.06.23.04 – 2018.06.23.05 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,目前 ICANN 每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。计划于 2020 年 3 月 7-12 日召开的第 67 届 ICANN 会议将在拉丁美洲/加勒比海地理区域内举行。为此,ICANN 于 2016 年 7 月 15 日发布了有关拉丁美洲/加勒比海地区会议举办地点的建议征询书。各个相关方向 ICANN 发送了提案。

      ICANN 组织对所有提案以及其他会场进行了全面分析并编制了一份报告,以确定符合“会议选址标准”(参见 http://meetings.icann.org/location-selection-criteria)的提案。依据提案和分析,ICANN 确认将墨西哥坎昆市作为第 67 届 ICANN 会议的举办地。

      董事会审核了 ICANN 组织关于在墨西哥坎昆市举行会议的简报、认为提案符合“会议选址标准”中重要因素的结论,以及与 2020 年 3 月 ICANN 公共会议所选设施相关的成本。董事会同意此建议。

      采取促进合同签订的此项行动是对 ICANN 使命的履行并符合公共利益,能够确保 ICANN 组织使用适合的第三方提供商,并确保以经济高效的方式,最大程度增加可用资源。该行动将有助于 ICANN 履行确保域名系统的安全、稳定与弹性的使命。

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

      董事会感谢所有为 ICANN 第 67 届会议的选址提供建议的人。

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

    5. 2020 年 6 月 ICANN 会议会场签约

      鉴于 ICANN 计划在亚太地区召开 2020 年第二次公共会议。

      鉴于 ICANN 组织已完成了对亚太地区拟议会场的全面审核,认为位于马来西亚吉隆坡的一个会场最为合适。

      兹此发布第 2018.06.23.06 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进与 2020 年 6 月在马来西亚吉隆坡举办的 ICANN 公共会议会场和酒店相关的所有必要的合同签订和费用支付工作,总金额不超过 [协商一致后确定的金额]。

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

      第 2018.06.23.06 – 2018.06.23.07 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,目前 ICANN 每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。计划于 2020 年 6 月 22-25 日召开的第 68 届 ICANN 会议,将在亚太地理区域内举行。为此,ICANN 于 2016 年 7 月 15 日发布了有关亚太地区会议举办地点的建议征询书。各个相关方向 ICANN 发送了提案。

      ICANN 组织对所有提案以及其他会场进行了全面分析并编制了一份报告,以确定符合“会议选址标准”(参见 http://meetings.icann.org/location-selection-criteria)的提案。依据提案和分析,ICANN 确认将马来西亚吉隆坡作为第 68 届 ICANN 会议的举办地。

      董事会审核了 ICANN 组织关于在马来西亚吉隆坡举行会议的简报、认为提案符合“会议选址标准”中重要因素的结论,以及与 2020 年 6 月 ICANN 公共会议所选设施相关的成本。董事会同意此建议。

      采取促进合同签订的此项行动是对 ICANN 使命的履行并符合公共利益,能够确保 ICANN 组织使用适合的第三方提供商,并确保以经济高效的方式,最大程度增加可用资源。该行动将有助于 ICANN 履行确保域名系统的安全、稳定与弹性的使命。

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

      董事会感谢所有为 ICANN 第 68 届会议的选址提供建议的人。

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

    6. 2020 年 10 月 ICANN 会议会场签约

      鉴于 ICANN 计划在欧洲地区召开 2020 年第三次公共会议。

      鉴于 ICANN 组织已完成了对欧洲地区拟议会场的全面审核,认为位于德国汉堡市的一个会场最为合适。

      兹此发布第 2018.06.23.08 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进与 2020 年 10 月在德国汉堡市举办的 ICANN 公共会议会场和酒店相关的所有必要的合同签订和费用支付工作,总金额不超过 [协商一致后确定的金额]。

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

      第 2018.06.23.08 – 2018.06.23.09 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,目前 ICANN 每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。计划于 2020 年 10 月 17-23 日召开的第 69 届 ICANN 会议,将在欧洲地理区域内举行。为此,ICANN 于 2016 年 7 月 15 日发布了有关欧洲会议举办地点的建议征询书。各个相关方向 ICANN 发送了提案。

      ICANN 组织对所有提案及其他会场进行了全面分析并编制了一份报告,以确定符合“会议选址标准”(参见 http://meetings.icann.org/location-selection-criteria)的会场。依据提案和分析,ICANN 确认将德国汉堡市作为第 69 届 ICANN 会议的举办地。

      董事会审核了 ICANN 组织关于在德国汉堡市举行会议的简报、认为提案符合“会议选址标准”中重要因素的结论,以及与 2020 年 10 月 ICANN 公共会议所选设施相关的成本。董事会同意此建议。

      采取促进合同签订的此项行动是对 ICANN 使命的履行并符合公共利益,能够确保 ICANN 组织使用适合的第三方提供商,并确保以经济高效的方式,最大程度增加可用资源。该行动将有助于 ICANN 履行确保域名系统的安全、稳定与弹性的使命。

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

      董事会感谢所有为 ICANN 第 69 届会议的选址提供建议的人。

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

    7. 考虑来自 SSAC 建议文件 SAC047、SAC058、SAC061、SAC090 和 SAC097 的建议

      鉴于安全与稳定咨询委员会 (SSAC) 在以下 SAC 文件中提交了建议:SAC047、SAC058、SAC061、SAC090 和 SAC097。

      鉴于 ICANN 组织评估了 SSAC 建议的可行性并针对各项建议制定了实施建议,或注意到了已完成的实施建议(如相关)。

      鉴于董事会考虑了 SSAC 建议和 ICANN 组织有关这些建议的实施建议。

      兹此发布第 2018.06.23.10 号决议:董事会采纳题为“ICANN 董事会针对 SSAC 建议文件 SAC047、SAC058、SAC061、SAC090 和 SAC097 采取的行动(2018 年 6 月 8 日)”的计分卡 [PDF, 182 KB],并指示总裁兼首席执行官或其指定人员实施计分卡中描述的建议。

      第 2018.06.23.10 号决议的理由

      行动请求注册是一个框架,旨在改进董事会考量提交至 ICANN 董事会的建议(包括来自 ICANN 咨询委员会的建议)的流程。该框架自 2015 年以来开始制定,初期工作包括由 ICANN 组织审核 2010 年至 2015 年间发布的 SSAC 建议,以确定尚未收到董事会建议的事项。ICANN 董事会主席于 2016 年 10 月 19 日向 SSAC 主席发送了一封信函,向其传达了这项初步审核的结果(参见 https://www.icann.org/en/system/files/correspondence/crocker-to-faltstrom-19oct16-en.pdf [PDF, 627 KB])。该决议旨在解决多个当时被确定为未决的事项,以及自 ARR 制定以来提交给 ICANN 董事会并由 ICANN 组织处理的两个事项。

      在行动请求注册流程中,对于本决议中提及的各项建议,ICANN 组织都审核了请求,与 SSAC 一道确认了其对于 SSAC 请求的理解,并评估了请求的实施可行性。

      各份文件的背景信息如下所示:

      建议文件 SAC047 [PDF, 197 KB] 中的建议 2 建议 ICANN 保留前注册管理机构的运营数据并定义一个与社群分享此类数据的框架。

      建议文件 SAC058 [PDF, 489 KB] 中的建议 3 建议 ICANN 社群尝试确定可以自动执行的身份验证技术。

      建议文件 SAC061 [PDF, 384 KB] 中的建议 2 建议 ICANN 董事会确保对注册数据政策进行正式的安全风险评估,以便为政策制定流程提供意见。

      建议文件 SAC090 [PDF, 255 KB] 中的建议 1 建议 ICANN 董事会采取适当措施来制定清晰且明确的标准,以确定语法上有效的域名标签是否可作为全球 DNS 中的顶级域。

      建议文件 SAC090 [PDF, 255 KB] 中的建议 2 建议,建议 1 中所述的工作范围至少应包括以下事项和问题:

      1. ICANN 是否应该在政策中正式确定以下名称的状态:《申请人指导手册》第 2.2.1.2.1 节中列出的保留名称和第 2.2.1.2.3 节列出的不合格字符串、参照《申请人指导手册》第 III 部分第 2.2.1.3.2 节禁用的双字符 ISO 3166 代码、参照申《申请人指导手册》第 2.2.1.4 节禁用的地理名称、RFC 6761 中列出的名称?如果是:i) ICANN 应如何应对其他方可能对 ICANN 认可但不在 ICANN 的直接控制范围内的清单进行的变更?ii) ICANN 应如何应对在新 gTLD 申请轮次期间对认可清单进行的变更?
      2. IETF 就是一个例子,它是 ICANN 外部的一个持有“特殊用途”域名的团体。对于 ICANN 外部主张拥有特殊域名清单的团体,ICANN 应对它们做出什么样的反应?
      3. ICANN 是否应在政策中正式确定私人使用域名的状态?如果是:i) ICANN 应如何处理 .corp、.home 和 .mail 等已知会与和 ICANN 认可的新 gTLD 相同的域名的正式申请发生大规模冲突的私人使用域名?ii) ICANN 应如何发现和应对日后出现的私人使用域名与拟议的 ICANN 认可的新 gTLD 之间的冲突?

      建议文件 SAC090 [PDF, 255 KB] 中的建议 3 建议 ICANN 董事会与 ICANN 之外的相关团体(包括 IETF)针对这些问题建立有效的合作方式。

      建议文件 SAC090 [PDF, 255 KB] 中的建议 4 建议 ICANN 在作出任何向全球 DNS 添加新 TLD 名称的决策之前,先完成建议 1 至 3。

      建议文件 SAC097 [PDF, 324 KB] 中的建议 1 建议 ICANN 董事会向 ICANN 组织提议考虑修订 CZDS 系统以解决默认情况下自动终止订阅的问题。

      建议文件 SAC097 [PDF, 324 KB] 中的建议 2 建议 ICANN 董事会向 ICANN 组织提议,确保在新 gTLD 的后续轮次中,CZDS 订阅协议符合因实施建议 1 而执行的变更。

      建议文件 SAC097 [PDF, 324 KB] 中的建议 3 建议 ICANN 董事会向 ICANN 组织提议,设法减少域文件访问投诉数量并及时解决投诉。

      建议文件 SAC097 [PDF, 324 KB] 中的建议 4 建议 ICANN 董事会向 ICANN 组织提议,根据所有 gTLD 注册管理运行机构的统一标准,确保准确和公开地报告域文件访问和基于网络的 WHOIS 查询统计数据。应明确域文件访问衡量标准。

      董事会接受这些建议项是符合公共利益的,并有助于推进 ICANN 使命的履行,因为它提高了 DNS 的安全性和稳定性。这些建议可以在 ICANN 组织的现有运营规划和预算中实施。

      在考虑这些建议项时,董事会审查了下列材料:

    8. 一般会员组织审核 — 最终报告和建议

      鉴于一般会员的第二次组织审核已根据《ICANN 章程》第 4 条第 4.4 款于 2016 年启动,其中《ICANN 章程》要求 ICANN 董事会“定期审核 … 各个咨询委员会 … 以确定:(i) 该组织、理事会或委员会是否在 ICANN 的架构中拥有继续存续的必要;(ii) 若有,则其架构或运营是否需要进行调整以提高效率;和 (iii) 该组织、理事会或委员会是否对其选区、利益相关方团体、各个组织和其他利益相关方负责”。

      鉴于进行第二次一般会员审核的独立审核人编制了报告草案(已于 2017 年 2 月发布征询公众意见)和最终报告(2017 年 5 月公布)。

      鉴于 ICANN 社群通过公众意见征询流程对报告草案提供了意见。

      鉴于一般会员审核工作组起草了一般会员审核建议可行性评估和实施规划,该实施规划获得了一般会员咨询委员会的批准。

      鉴于 ICANN 董事会组织效率委员会 (OEC) 在其 2017 年 9 月 21 日的会议期间收到了来自独立审核人有关最终报告的简报以及来自一般会员审核工作组有关一般会员审核建议可行性评估和实施规划的简报。

      鉴于 OEC 在其 2017 年 12 月 6 日的会议期间批准了一份映射文件,该文件描绘了在最终报告以及一般会员审核建议可行性评估和实施规划中发现的基本问题。

      鉴于该映射文件强调了最终报告与一般会员审核建议可行性评估和实施规划之间的差异,OEC 向 RWP 提出了一系列问题,因为 OEC 同意“在向董事会提供有关最终报告或可行性研究的建议之前,需要就该主题与审核工作组展开进一步讨论”。

      鉴于为了回复该映射文件,一般会员审核工作组起草了一般会员审核实施概述提案,该提案已获得 ALAC 批准并提交给 OEC 考虑。

      鉴于在提交一般会员审核实施概述提案之后,非商业利益相关方团体和 GNSO 理事会的签约方机构针对审核向 ICANN 董事会提交了其他信函,为回复这些信函 ALAC 向 OEC 提供了其他信息。OEC 认为 ALAC 已经适当地考虑了提出的问题。

      鉴于为了向董事会提出有关如何进行一般会员组织审核的建议,OEC 在 2018 年 5 月 29 日的会议上考虑了所有相关文件和公众意见。

      兹此发布第 2018.06.23.11 号决议:董事会收到了独立审核人的一般会员审核最终报告。

      第 2018.06.23.12 号决议:董事会接受 ALAC 于 2017 年 8 月 22 日批准的一般会员审核建议可行性评估和实施规划,以及 ALAC 于 2018 年 4 月 20 日批准的由一般会员审核工作组起草的一般会员审核实施概述提案。

      第 2018.06.23.13 号决议:董事会指示 ALAC 组建一般会员审核实施工作组,负责监督一般会员审核实施概述提案中包含的实施提案的实施流程,包括通过制定详细的实施规划。董事会希望该实施规划将进一步阐述一般会员审核实施概述提案中详细描述的各个实施步骤(包括通过确定各项实施步骤的衡量标准),简要概述 ALAC 的各项提案的当前状态,明确定义的实施目标以及如何持续测量实施进度的方法。

      第 2018.06.23.14 号决议:董事会指示 ALAC 与 ICANN 组织合作,将各个实施步骤的预期预算影响纳入其详细的实施规划中。该实施规划应纳入分阶段方法,允许首先实现易于实施且成本最低的改进,对于那些具有更明显预算影响的项目,则通过后续预算周期解决。任何预算申请应根据 ICANN 组织的预算编制流程提出。详细的实施规划应尽快提交给董事会,但不得晚于通过该决议后六 (6) 个月。

      第 2018.06.23.15 号决议:董事会指示一般会员审核实施工作组向 OEC 提供有关实施规划进度的半年度书面实施报告,包括但不限于实施规划中详述的衡量标准的完成进度以及所分配预算的使用情况。

      第 2018.06.23.11 – 2018.06.23.15 号决议的理由

      为确保 ICANN 的多利益相关方模型保持透明、负责并帮助提高其绩效,ICANN 依照其《ICANN 章程》第 4 条第 4.4 款所述,对其支持组织和咨询委员会进行了章程规定的组织审核。第二次一般会员审核于 2016 年 5 月启动。

      独立审核

      2016 年 5 月,根据 ICANN 的聘用流程,ITEMS International 被任命为一般会员审核的独立审核人。ICANN 的聘用流程使得 ICANN 组织人员和董事会组织效率委员会 (OEC) 得以参与进来,后者负责监督组织审核流程。在其工作期间,ITEMS 审核了相关文档,与一般会员社群、ICANN 社群、ICANN 董事会和 ICANN 组织的成员进行了 100 多次面对面访谈。ITEMS 的调查收集了 242 项单独回复。此外,ITEMS 还与 RWP 召开了 15 次电话会议和三次面对面会议,并在社群范围内召开了两次网络研讨会。根据标准的 ICANN 流程,公布了报告草案 [PDF, 2.31 MB] 以征询公众意见。

      RWP 也向独立审核人提供了有关报告草案 [PDF, 2.31 MB] 和最终报告 [PDF, 4.04 MB] 的初步草案的直接反馈。ITEMS 考虑了该反馈,根据其独立角色和专业判断纳入了其认为适当的要素。

      2017 年 5 月 1 日,ITEMS 向 ICANN 提交了其最终报告 [PDF, 4.04 MB]。最终报告叙述了独立审核人发现的基本问题以及独立审核人作为解决这些问题的提案提出的 16 项建议。这些建议的核心是根据所谓的“赋权会员模型”重组一般会员的提案。

      一般会员审核工作组/ALAC 意见

      RWP 同意最终报告 [PDF, 4.04 MB] 中提出的一些问题。董事会指出,RWP 担心包括赋权会员模型在内的很多建议要么不可实施,要么(如果在不加以修改的情况下实施)可能会对一般会员社群不利,因为这些建议可能会导致偏离《ICANN 章程》第 12.2(d) 条中规定的组织愿景和职能。RWP 在 ALAC 于 2017 年 8 月 22 日批准的其一般会员审核建议可行性评估和实施规划 [PDF, 556 KB] 中针对其担忧提供了详细的理由。

      RWP 起草了一般会员审核实施概述提案,该提案于 2018 年 4 月 20 日由 ALAC 批准,其中提供了有关审核结果的额外意见并提出了解决独立审核人确定的且一般会员社群同意的那些基本问题的备选提案。

      ICANN 社群的意见

      除了独立审核人通过访谈和在线调查收集的回复外,在有关独立审核人的报告草案 [PDF, 2.31 MB] 的公众意见征询期内,总共提交了 15 项意见,其中五项由个人贡献者提交,十项由组织提交(包括附属于一般会员社群的五个组织)。请参见公众意见征询程序之工作人员报告 [PDF, 1.07 MB]。从总体上看,来自一般会员社群(包括 ALAC、RALO 和一些 ALS)的意见对 ITEMS 的报告草案持批评态度。特别是,ALAC 指出“ALAC 和审核工作组坚持认为无需组建工作组 (WG);服务于 RALO 领导人双重角色的 ALAC 成员工作量过大;参与 AC/SO WG 协调和编写声明工作的报告员知识和经验极其不足;大量排挤‘老前辈’,几乎看不到他们;联络人无法完成其工作(或被其目标组织拒绝),这样,我们将成功使一般会员不再服务于 ICANN 或不再能够保障最终用户的利益。”

      其他评论者则很少批评 ITEMS 的报告,至少支持赋权会员模型提案的一些方面并同意 ITEMS 的很多评估和建议。例如,注册管理机构利益相关方团体 (RySG) 指出“我们支持一般会员的使命对于 ICANN 很重要但该使命的履行已经受到一般会员当前形式的限制的结论。”企业和商业用户选区 (CBUC)“支持赋权会员模型 (EMM) 的一些方面。”同样,非商业利益相关方团体 (NCSG) 认为“ITEMS 报告确定的很多问题确实存在。特别是:过于关注内部委员会和程序,以及过去关注扩大 ALAC 在 ICANN 生态系统中获得的权力和资源。”

      OEC 和董事会的考量及行动

      作为负责监督组织审核的 ICANN 董事会委员会,OEC 详细审核了与一般会员审核有关的所有相关文件。具体而言,OEC 考虑了最终报告 [PDF, 4.04 MB] 和一般会员审核建议可行性评估和实施规划 [PDF, 556 Kb],并分别收到了来自独立审核人和 RWP 的简报和意见。根据这些简报,OEC 随后命令 ICANN 组织编写一份映射文件 [PDF, 707 KB],OEC 将该文件发给 RWP,其中包含几个问题。反过来,该映射文件促使 RWP 起草了一般会员审核实施概述提案。虽然该提案并未回复映射文件中包含的问题,但却针对解决独立审核人提出的问题提供了详细的意见;并且还提出了一系列经 ALAC 批准的实施提案。

      公布一般会员审核实施概述提案后,CPH [PDF, 60 KB]、NCSG [PDF, 163 KB] 和提交了匿名信的组织 Atlarge.watch 致信 ICANN 董事会。CPH 和 NCSG 均跟进了其公众意见,并表达了担忧:在他们看来,一般会员审核实施概述提案并未解决映射文件 [PDF, 707 KB] 中提出的问题,也未对一般会员审核报告中提出的具体批评做出回应。NCSG 表示,实施提案“将不会解决审核人和更广大的社群确定的其中一些最重要和最基本的问题”。NCSG 和 CPH 都要求更新实施概述以解决映射文件中的所有问题,并实现“提交给整个 ICANN 社群,以便从社群中获得任何进一步的意见或安排与社群进行进一步的讨论,以使审核达到适当的目的”的结果。

      董事会注意到了这些问题,并已将它们与该审核流程中收到的所有其他社群意见一同考虑。董事会认为,再进行一轮公众意见征询不符合组织审核流程,可能会不必要地延长进行第二次一般会员审核和实现改进的时间。关于 CPH [PDF, 60 KB] 和 NCSG [PDF, 163 KB] 发送的信函,ALAC 对其进行了富有成效的讨论并以实质性和详细的方式做出了回复 [PDF, 177 Kb],这才促使 OEC 提出了建议以及董事会随后采取行动。考虑到提供的回复,OEC 建议且董事会同意:继续推进一般会员审核是合适的,基于讨论和 ALAC 提供的保证,RWP 没有必要再回答映射文件 [PDF, 707 KB] 中提出的问题。

      考虑到 ALAC 的立场,包括其对社群问题的回复,董事会认为 ALAC 已经在该组织审核流程中展示了问责制和透明度。此外,董事会认为一般会员审核实施概述提案适当回复了审核过程中提出的问题,希望通过实施该提案一般会员可以获得更大改善,并进一步提高最终用户在 ICANN 多利益相关方模型中的参与度。虽然所追寻的建议路径明显偏离了独立审核人的建议,但董事会认为,基于其所看到的一切情况,实施建议是适合解决独立审核人的报告中充分描述的问题的。实现 ALAC 提议的改进是确保审核后一般会员能够履行章程规定的角色和职责的一个重要步骤。

      为了确认 ALAC 适当地推进该流程,董事会指示 ALAC 向其提供扩展的实施规划,包括简要概述 ALAC 的各项实施提案的当前状态、明确定义的实施目标、优先次序和资源影响以及如何持续测量实施进度的方法。董事会认为这些衡量标准将有助于确保实施流程的问责制和透明度,促成有意义的改进,从而进一步加强章程中规定的一般会员在 ICANN 中代表最终用户利益的关键性角色。

      从总体上看,董事会注意到了章程第 4.4 款中规定的组织审核流程的重要性。自一般会员审核流程启动以来,OEC 和 ICANN 组织已经实施了对更广泛组织审核流程进行的更改,以便解决在该一般会员审核中发现的程序问题,特别是避免使其他审核出现 RWP 和独立审核人无法约定如何处理基本问题和适当建议的相同情况。值得注意的是,组织审核流程(对于在此第二次一般会员审核后进行的所有审核)现在包括两个阶段,第一个阶段只集中于对接受审核的组织进行评估。第二个阶段于独立审核人和接受审核的组织之间就评估实质上达成一致后开始,重点是提出改进建议。这个两阶段的审核方案将减少在一般会员审核期间出现的类似结果,并将改进组织审核流程以及接受审核的组织的问责制。

      组织审核流程是一个重复性流程,董事会希望 ICANN 社群的所有部分将继续开展卓有成效的工作,以便了解各个 SO/AC 的独特角色以及它们带给 ICANN、其政策制定工作和跨社群工作的观点,我们期望下一轮审核能够继续完善和实现流程改进。

      正在考虑的提案是什么?

      董事会考虑了接受最终报告 [PDF, 4.04 MB]、一般会员审核建议可行性评估和实施规划 [PDF, 556 KB] 和一般会员审核实施概述提案(后两项均已获得 ALAC 批准)的提案。此外,董事会还考虑指示 ALAC 组建实施团队。实施团队应起草实施规划,并向 OEC 每半年提供详细说明实施进度的书面报告。由于独立审核人的一些建议要么不可实施,要么(如果在不加以修改的情况下实施)可能会导致偏离一般会员的愿景和职能,董事会正在考虑是否指示 ALAC 使用一般会员审核实施概述提案来代替最终报告,以便合理地解决独立审核人确定的基本问题,从而为实施流程提供指导。

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

      董事会审核了:包含 16 项建议的独立审核人的 ICANN 一般会员社群最终报告审核 [PDF, 4.04 MB];ALAC 批准的一般会员审核建议可行性评估和实施规划 [PDF, 556 KB];ICANN 组织在 OEC 的要求下编制的映射文件 [PDF, 707 Kb];以及 ALAC 批准的一般会员审核实施概述提案。董事会还审核了所有公众意见以及工作人员整理的公众意见摘要 [PDF, 1.07 MB],包括 CPH [PDF, 60 KB] 和 NCSG [PDF, 163 KB] 发送的信函。基于这些审核以及 OEC 提出的建议,董事会同意一般会员审核实施概述提案应作为实施工作的指导性文件。

      是否会在财务方面对 ICANN(战略规划、运营规划或预算)产生影响或不良后果?

      对于一般会员审核实施概述提案中详述的提高 ALAC 和一般会员的效率的工作,可能需要董事会批准的 2019 财年运营规划和预算中不包含的额外资源。针对这项行动,ALAC 被指示组建实施团队,该团队将计划、执行和报告实施工作。应起草详细的实施规划,包括预算/资源影响(如适用),该实施规划应纳入分阶段方法,允许首先实施易于实施且成本最低的建议,对于具有更明显预算影响的建议,则通过 2020 财年预算周期解决。

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

      该行动预计不会对 DNS 的安全、稳定或弹性造成直接影响。

      董事会采取行动前是否需要征询公众意见?

      2017 年 2 月发布报告草案 [PDF, 2.31 MB] 后,已公开征询公众意见。因此不需要进一步征询公众意见。

      符合 ICANN 的使命并服务于全球公共利益

      这项行动支持 ICANN 所有部分问责制的有效性和持续改进,它符合 ICANN 的使命并服务于全球公共利益。

    9. 感谢第 62 届 ICANN 会议的当地主办机构

      董事会希望对欧文·A·哈曼(Irvin A. Halman,巴拿马政府创新国家机构 [The National Authority of Government Innovation] 总负责人)、巴勃罗·A·鲁伊迪亚斯·M(Pablo A. Ruidiaz M.,巴拿马政府创新国家机构互联网、包容性和移动性负责人)以及当地主办机构(巴拿马政府创新国家机构)表示感谢。

    10. 感谢第 62 届 ICANN 会议的赞助商

      董事会希望对以下赞助商表示感谢:Verisign

    11. 感谢第 62 届 ICANN 会议的口译员、工作人员以及会议和酒店团队

      董事会对速记员、口译员、视听团队、技术团队和全体 ICANN 工作人员为会议顺利进行所付出的努力表示最深的谢意。董事会还要感谢都市会议中心 (Megapolis Convention Center) 的管理层和工作人员为召开本次会议提供了优良的场所和设施。特别感谢以下人士:詹妮·巴拉奥纳(Gianni Barahona,活动策划经理)、阿尼亚·布伊特拉戈(Ania Buitrago,国际活动助理主任)、胡里奥·亚历杭德罗·卡兰奇(Julio Alejandro Calanche,国际销售经理)、杰勒德·阿尔瓦拉多(Gerardo Alvarado,IT 经理)以及安德烈斯·阿尔贝托·巴斯克斯(Andres Alberto Vásquez,来自 Eleven Producciones)。

  2. 主要议程:

    1. 对重审请求 18-3 的考量:Astutium Ltd.

      未达成任何决议。

    2. 对重审请求 18-1 的考量:DotMusic Limited

      未达成任何决议。

    3. 对重审请求 18-2 的考量:dotgay LLC

      未达成任何决议。

    4. 其他事务

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