Skip to main content
Resources

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

本页面还提供其他语种:

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

 

  1. 认可议程
    1. 批准理事会会议记录
    2. 授权阿拉伯文的"伊朗"这一 ccTLD
    3. GNSO 针对"根据 UDRP 程序锁定域名"提出的 PDP 建议
    4. 国家或地区代码域名支持组织 (ccNSO) 审核实施
    5. GNSO 审查
  2. 主要议程
    1. 任命 2014 年提名委员会主席和候任主席
    2. 处理新 gTLD 历史成本
    3. GNSO 利益主体组织和社群章程的修正流程提案
    4. 根据 AoC 审查对新 gTLD 计划的竞争、消费者信任和消费者选择衡量标准 进行澄清

 

  1. 认可议程:

    1. 批准理事会会议记录

      兹发布第 2013.09.28.01 号决议:理事会批准 2013 年 7 月 17 日、7 月 18 日和 8 月 22 日的 ICANN 理事会会议记录。

    2. 授权阿拉伯文的 "伊朗"这一 ccTLD

      兹发布第 2013.09.28.02 号决议:ICANN 在依照 IANA 职能合同规定履行其职责的过程中,审核并评估了将 ایران ("伊朗")这一国家或地区代码顶级域名授权给 Institutefor Research in Fundamental Sciences(基础科学研究所)的请求。文档显示,在评估此请求时,工作人员严格遵守了相应流程。

      兹发布第 2013.09.28.03 号决议:为了履行合同义务,决议、初步报告或会议记录中的部分理由目前不宜公诸于众。根据《ICANN 章程》第 III 条第 5.2 款,理事会要求保留这部分理由,并等待适当时机再予以公布。

      第 2013.09.28.02 – 2013.09.28.03号决议的理由

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

      根据 IANA 职能合同的要求,ICANN 工作人员已评估一个授权 ccTLD 的请求,且目前正在准备报告,以提请理事会审核。提请理事会审核的目的是确保 ICANN 工作人员严格遵守相应流程。

      正在考虑的提案是什么?

      该提案旨在批准向 ICANN 的 IANA 部门提交的一项请求,该请求希望创建国家或地区代码顶级域名并将主办组织(也称为管理者或受托者)的角色分配给基础科学研究所。

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

      在授权申请的评估过程中,ICANN 工作人员咨询了申请人和其他利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其在当地互联网群体中的影响力。

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

      工作人员没有收到机构群体就此请求提出的任何重要意见和建议。

      [编辑理由]

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

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

      是否会对机构群体产生积极或者消极影响?

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

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

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

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

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

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

    3. GNSO针对"根据 UDRP 程序锁定域名"提出的 PDP 建议

      鉴于 2011 年 12 月 15 日,GNSO 委员会针对"根据 UDRP 程序锁定域名"推出了相应的政策制定流程 (PDP),以解决五个章程问题,详情见 https://community.icann.org/x/ma-bAQ

      鉴于 PDP 遵循了章程中所规定的 PDP 步骤,最终于 2013 年 7 月 5 日提交了《最终报告》。

      鉴于"根据 UDRP 程序锁定域名"工作组 (WG) 就章程所列问题的相关建议完全达成共识。

      鉴于 GNSO 委员会审核并讨论了根据 UDRP 程序锁定域名工作组的建议,并于 2013 年 8 月 1 日通过绝大多数和一致投票采纳了这些建议(请访问 http://gnso.icann.org/en/council/resolutions#201308)。

      鉴于 GNSO 委员会投票达到并超过了为 ICANN 合同签约方增加新义务所需的投票门槛。

      鉴于在 GNSO 委员会投票后,就批准的建议开放了公众意见征询期,并就征集到的意见进行了总结和考量 (http://www.icann.org/en/news/public-comment/locking-domain-name-recommendations-02aug13-en.htm)。

      兹发布第 2013.09.28.04 号决议:理事会采纳了 GNSO 委员会针对"根据 UDRP 程序锁定域名"提出的政策建议,详情见《最终报告》(请访问 http://gnso.icann.org/zh/issues/locking/domain-name-final-05jul13-zh.pdf [PDF, 1.13 MB])。

      兹发布第 2013.09.28.05 号决议:指示总裁兼首席执行官制定并完成针对这些建议的实施计划,并继续就此工作与机构群体沟通。

      第 2013.09.28.04 – 2013.09.28.05号决议的理由

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

      目前,在提请投诉之后到诉讼程序开始之前的期间内不需要锁定域名,也没有对"现状"给予定义,因而导致对政策出现不同的解读并产生混淆。为解决此问题,GNSO 委员会决定于 2011 年 12 月 15 日启动政策制定流程 (PDP)。在其审议过程中,委员会要求工作组考虑以下问题:

      1. 制定拟议程序的大纲,投诉人必须遵循该大纲,以便注册服务商将域名置于注册服务商锁定,这一做法是否可行。

      2. 制定注册服务商有理由预计会在 UDRP 争议期间进行的流程步骤大纲,这一做法是否可行。

      3. 是否应对提交 UDRP 后注册服务商必须锁定域名的时间范围制定标准。

      4. a. 是否应定义构成"锁定"域名的条件。

        b. 根据 UDRP 程序"锁定"域名后,是否可以更改或修改该域名的注册人信息。

      5. 在已根据 UDRP 程序锁定域名的情况下,是否应采取额外的保护措施来保护注册人。

      工作组于 2013 年 3 月 15 日发布了《初步报告》以征询公众意见,随后又在 2013 年 7 月 5 日发布了《最终报告》,该报告取得了 PDP 工作组和 GNSO 委员会的一致共识。公众意见征询期结束后,根据《ICANN 章程》附录 A,下一步是由 ICANN 理事会考虑这些建议。

      正在考虑的提案是什么?

      正在考虑以下建议:

      建议 1:在此背景下,术语"锁定"是指防止注册服务商和注册人进行任何更改。此类"锁定"不应仅以提交了 UDRP 投诉或正在进行 UDRP 程序的事实为依据对域名解析造成影响。1

      建议 2:修改 UDRP 规则中的下列条文,即:将投诉提交给 UDRP 提供商后,投诉人还应"说明已将投诉 […] 副本发送或传达给被投诉人"(第 3 部分,b – xii),并建议最佳做法应是投诉人无需通知被投诉人已呈交投诉书,以防止域名规避。程序正式启动后,UDRP 提供商将负责立即通知被投诉人。

      建议 3:收到投诉后,UDRP 提供商将在进行初步缺陷检查2后,向注册服务商发送验证请求,包括请求避免对域名注册的注册服务商和注册人进行任何更改("锁定")。注册服务商不允许将未决程序通知注册人,但在已避免对注册服务商和注册人进行任何更改时可进行通知。如果是委任的代理/隐私提供商3或注册服务商的附属代理/隐私提供商,那么注册服务商可联系该委任/附属的代理/隐私提供商,以便允许披露代理客户资料。但是,只能在实施初步锁定并避免对注册服务商和注册人进行任何更改后,才能进行此类联系。

      建议 4:最晚在收到 UDRP 提供商发来的验证请求后 2 个工作日4内,注册服务商应修改注册状态,以避免对注册服务商和注册人进行任何更改("锁定")。注册服务商必须在 UDRP 程序的剩余未决期内继续避免此类更改,UDRP 程序暂停的情况除外(请参阅建议 10)。未决期被定义为自投诉人将关于域名的 UDRP 投诉或发起审判程序或仲裁的相关文件提交给 UDRP 提供商之时开始,具体视情形而定。对于因委任/附属的隐私/代理提供商请求披露基本代理客户资料而进行的任何更新5,必须在 2 个工作日的时间段结束前,或在注册服务商确认所申请的信息并向 UDRP 提供商确认锁定之前进行,两个时间以更早一个为准。

      注册服务商收到 UDRP 提供商发来的验证请求后,不应允许转让到另一注册人6或注册服务商,但是以下特殊情况例外:涉及未按政策进行的仲裁时,或涉及 UDRP 政策第 8(a) 或 8(b) 款规定的诉讼时。依据 UDRP 之目的,锁定时列在 Whois 记录中的注册人将被记为被投诉人。在依据政策的行政程序未决期内,可以根据注册服务商的适用政策和合同允许或禁止对 Whois 信息的任何更改,但是据 UDRP 规则 2(e) 和 UDRP 规则 5(b)(ii),注册人有责任将可能影响 UDRP 中提供商对被投诉人的通知责任和义务的任何相关更新通知提供商。

       根据隐私/代理服务的条款,注册服务商可选择向提供商披露由于隐私/代理服务而得知的基本资料,或 Whois 中的基本资料,或披露两者(如果知道)。如果所进行的"转让"符合草案建议 2,则不会视为违反上述规定。如果实施锁定后隐私/代理服务被披露或代理客户信息被发布,且提供商收到通知,提供商没有义务要求投诉人相应修改其投诉,但可自行决定做此要求。依据 UDRP 规则 2(e) 和 UDRP 规则 5(b)(ii),注册人有责任将可能影响 UDRP 中提供商对被投诉人的通知责任和义务的任何相关更新通知提供商,且提供商在得知该更新时,应立即根据 UDRP 以其偏好的细节程度向被投诉人提供案件信息。例如,UDRP 规则 5(b)(iii) 要求提供商将通讯发送到被投诉人偏好的电子邮箱地址。

      建议 5:作为最佳实践,应鼓励注册服务商和 UDRP 提供商提供允许第三方确定其各自的开始时间/日期的方法,在此期间有望执行 UDRP 相关任务。

      建议 6:注册服务商必须在收到 UDRP 提供商发来的验证7 请求后 2 个工作日内,向 UDRP 提供商确认:已阻止对注册服务商和注册人进行任何更改,且在程序的未决期内也将予以阻止,注册服务商还必须确认8UDRP 提供商请求验证的信息。

      建议 7:如果认为会遵从,UDRP 提供商应将投诉状转发给注册服务商和被投诉人,并不晚于收到投诉人支付的费用后 3 个工作日9,通知他们行政程序启动。

      建议 810授予相关 UDRP 被投诉人请求延期四天的明确选择权,在收到任何此类延期四天申请时自动批准,UDRP 提供商延长相应的截止期限,并不向被投诉人收取费用。这一根据请求自动延期四天的方案的可用性也应由 UDRP 提供商在被投诉人关于程序开始的信息上进行标记,并且不妨碍 UDRP 提供商根据 UDRP 规则第 5d 条可能批准的任何其他延期请求。

      建议 9:如果依据 UDRP 政策第 4 条进行的行政缺陷检查期结束后,投诉状仍然不符合要求,或未支付费用,或者投诉人在该期间自动撤诉,UDRP 提供商将通知注册服务商该程序已撤销。 注册服务商应在收到撤销通知后一个工作日内,解除相关的 "锁定"。

       建议 10:在发送给注册人的通知(投诉通知 – 请参阅 UDRP 规则的第 4 节)中,UDRP 提供商将告知注册人:依据 UDRP 规则 5(ii) 和 (iii),在程序剩余未决期内对注册人联系信息的任何更改也要求传达给 UDRP 提供商。

      建议 11:该通知还应包含这一信息:"锁定"后取消代理/隐私服务而产生的任何更改必须由 UDRP 专家组直接讨论/处理。工作组建议该问题作为隐私/代理委任计划制定工作的一部分继续审核。

      建议 12:依据 UDRP 规则 16 和 UDRP 政策第 4(k) 和 8(a) 款,注册服务商收到提供商关于决定的通讯后,必须在 3 个工作日内告知各方(提供商和 ICANN)实施该决定的日期。根据 UDRP 政策第 4(k) 款,如果投诉人胜诉,注册服务商应在 10 个工作日后立即执行专家组判决。投诉人或其授权代表必须向注册服务商提供执行小组判决所需的信息;这可能包括应在 Whois 中出现的信息。如果被投诉人胜诉,那么在收到提供商发来的判决之日起 15 个工作日内,注册服务商应避免将相关域名转让给另一注册服务商或注册人(UDRP 政策第 8 条)。

      建议 13:程序暂停时(双方试图和解时),UDRP 提供商应告知注册服务商相关暂停事项,包括预计的暂停时长。如果双方达成和解协议,有关注册的转让、撤销或同意仍归被投诉人所有,注册服务商必须在 UDRP 提供商确认双方达成和解协议后 2 个工作日内,解除为避免转让或撤销而实施的任何锁定,除非有争议的域名注册是已开始的法庭诉讼的主题。

      建议 14:和解流程必须遵循以下步骤:(1) 双方要求 UDRP 提供商暂停程序,(2) 双方达成和解,(3) 双方向 UDRP 提供商提交标准的"和解协议",(4) UDRP 提供商向注册服务商确认(复制双方协议)和解协议条款是否表明被投诉人同意将有争议的域名转让给投诉人或将其撤销,或投诉人同意域名仍归被投诉人所有,(5) 注册服务商执行和解协议,(6) 投诉人向 UDRP 提供商确认执行,以及 (7) UDRP 提供商撤销诉讼。

      建议 15:ICANN 理事会通过这些建议后,ICANN 与 UDRP 提供商、注册服务商和其他相关方共同制定培训和资讯材料,促使受影响的各方知悉这些要求和建议的最佳做法。

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

      根据章程要求,PDP 工作组应"首先征询关于这一问题的公众意见,以便清楚地了解根据 UDRP 程序锁定域名所遇到问题的准确性质和范围"。因此,工作组在注册服务商以及 UDRP 提供商之间开展了一次调查,如《最终报告》第 5.1 节所述。除了关于注册服务商和 UDRP 提供商的实践和经验的具体问题外,还要求受访者提供关于章程问题的意见。此外,工作组还于 2012 年 7 月 25 日开放了公众意见论坛,以征询机构群体意见。

      除了对 GNSO 委员会的定期更新外,还组织了研讨会以在 ICANN 会议上报告并征询 ICANN 机构群体的意见(示例见 http://beijing46.icann.org/zh/node/37829http://toronto45.icann.org/node/34245http://prague44.icann.org/node/31807)。

      在该流程的初步阶段,请求了社群/利益主体组织声明,并征询了其他 ICANN 支持组织和咨询委员会的意见。但没有收到这些请求的回应。PDP 工作组主席在 ICANN 布拉格会议上会见了 ccNSO,就这一主题交换了意见(更多详细信息,请访问 http://ccnso.icann.org/meetings/toronto/summary.htm#neylon-greenberg)。

      工作组于 2013 年 3 月 15 日针对《初步报告》开放了一个公众意见论坛

      "根据 UDRP 程序锁定域名"PDP 工作组审核并考量了收到的所有意见(参见《最终报告》第 6 节)。

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

      对于最终报告及其意见,机构群体没有提出任何疑虑。PDP 工作组审核并处理了收到的所有其他意见,详情见《最终报告》第 6 节。

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

      理事会审核了 GNSO 委员会提交给理事会的建议报告以及公众意见摘要。

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

      建议根据《ICANN 章程》附录 A 中所述的 GNSO 政策制定流程 (PDP) 制定,并且已获得 GNSO 委员会的一致支持。如《ICANN 章程》所述,委员会对动议的一致(绝大多数)支持会促使理事会采纳建议,除非有超过 66% 的理事会成员投票表示该政策并不符合 ICANN 机构群体或 ICANN 的最佳利益。

       是否会对机构群体产生积极或者消极影响?

      采纳这些意见应该可以帮助包括投诉人、被投诉人、注册服务商以及 UDRP 提供商在内的所有相关方明确和标准化根据 UDRP 程序锁定域名的流程。实施这些建议除了需要对 UDRP 提供商的做法进行一定的修改外,还要对一些注册服务商流程进行一定的修改,因为目前尚未实施根据 UDRP 程序锁定域名的标准化处理流程。对于投诉人,主要的变化是投诉时,投诉人不再需要通知被投诉人,以此减少域名规避的发生(由 UDRP 提供商在诉讼正式开始时通知被投诉人)。由于投诉人在提交投诉时无需再通知被投诉人,这一改变有望减少被投诉人的非正式回应时间。但是,为了补偿非正式回应可能造成的时间损失,建议授予相关 UDRP 被投诉人请求延期四天的明确选择权,在收到任何此类延期四天请求时自动批准,然后 UDRP 提供商就会延长相应的截止期限,并不向被投诉人收取任何费用。

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

      除了上述注册服务商和 UDRP 提供商流程所需的更改,可能还会造成与实施政策相关的财务影响,但是这些费用预计都包括在当前预算之内。

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

      如果理事会批准提出的建议,则不会出现与 DNS 相关的任何安全性、稳定性或灵活性问题。

    4. 国家或地区代码域名支持组织(ccNSO) 审核实施

      鉴于 2011 年 4 月 21 日,理事会决定指派 ICANN 工作人员与机构改进委员会 (SIC) 进行协调,以便针对 理事会 ccNSO 审核工作组最终报告 [PDF, 716 KB] 中的建议,拟定实施计划和时间表提案,并将这些提案提交给机构改进委员会进行审查,以及提交给理事会进行批准(决议 2011.04.21.06)。

      鉴于在其 2011 年 6 月 18 日的会议上,确认收到了工作人员于 2011 年 6 月 9 日提交的名为"改进实施项目计划"的实施计划,并决定向 ICANN 理事会推荐以获得批准。

      鉴于在 2011 年 6 月 24 日会议上,理事会决定要求 ICANN CEO 指示工作人员根据 2011 年 6 月 9 日提交的名为ccNSO 改进实施项目计划 [PDF, 508 KB] 的实施计划文档继续开展实施工作(第 2011.06.24.03 号决议)。

      鉴于 2013 年 9 月 27 日,SIC 确认收到一封来自 ccNSO 主席的信函,其中提到作为对 2013 年 9 月 ccNSO 实施项目计划最终更新的补充,ccNSO 审查实施工作已完成。

      鉴于在 2013 年 9 月27 日,SIC 同意建议 ICANN 理事会接受 2013 年 9 月的 ccNSO 实施项目计划最终更新 [PDF, 170 KB]、关注 ccNSO 审查实施阶段的完成情况,以及开始审查周期内固有的评估阶段。

      兹发布第 2013.09.28.06 号决议:理事会接受 2013 年 9 月的 ccNSO 实施项目计划最终更新,并关注 ccNSO 审查建议的实施完成情况。

      兹发布第 2013.09.28.07 号决议:理事会指示 ICANN 总裁兼首席执行官按照组织审查周期的评估阶段,对 ccNSO 审查得出的改善进行评估。

      兹发布第 2013.09.28.08 号决议:理事会对 ccNSO 开展的实施工作表示感谢。

      第 2013.09.28.06 – 2013.09.28.08号决议的理由

      根据《ICANN 章程》,需要定期审查 ICANN SO/AC 以评估受审实体的表现和运营效率。审核的目的是确定:(i) 作为 ICANN 组织结构的一部分,该组织是否具有长期的目标,(ii) 如果有,那么对其结构或运营方式的任何更改是否有助于提高其效力。"

      此举措是对理事会希望实施 ccNSO 审查得出的建议的直接回应,其作用是及时启动对 ccNSO 审查改善的评估。

      该举措不涉及任何复杂的结构调整或预算影响。此举措预计不会对域名系统的安全性、稳定性和灵活性造成影响。

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

    5. GNSO 审查

      鉴于根据 ICANN 的章程,下一次 GNSO 审查应在 2013 年开始。

      鉴于 SIC 就是否应推迟该审查以及是否应在未来六个月内为该审查制定时间表征询并考量了公众意见。

      鉴于 GNSO 审查必须顾及 ICANN 的战略规划工作以及问责制和透明度审核小组 2 的工作,这两项工作只能在 2014 年通过启动 GNSO 审查来完成。

      兹发布第 2013.09.28.09 号决议:理事会指示 SIC 按照《ICANN 章程》第 IV 条第 4 款的规定,安排在 2014 年审查通用名称支持组织 (GNSO),并尽快启动执行该审查的准备工作。

      第 2013.09.28.09号决议的理由

      《ICANN 章程》要求定期审查 ICANN 的内部组织结构,以维持 ICANN 的问责制。为此,2006 年便启动了首次 GNSO 组织审查。在此次审查中,2006 年 9 月公共政策团体与企业 LSE (负责执行该审查的独立审查方)发布了一份报告;2008 年 2 月 3 日理事会监管委员会 GNSO 审查工作组发布了关于 GNSO 改进的报告。根据《ICANN 章程》第 IV 条第 4 款的规定,下一次审查将在最终报告发布 5 年后开始,即要求在 2013 年初开始审查。机构改进委员会 (SIC) 向理事会进言,认为推迟开始新一轮的 GNSO 审查,以便纳入在 ICANN 战略规划流程以及根据义务确认书组建的第二问责制和透明度审核小组 (ATRT 2) 正在进行的工作中收集的宝贵意见。公众意见征询期于 2013 年 7 月 15 日开放,以就可能推迟 GNSO 审查的问题收集意见,用于指示 SIC 的行动。在该公众意见征询期内收到了八个来自机构群体的回应,其中有七个回应者表示不应推迟 GNSO 审查。列举的理由包括:

      • TLD 空间的扩展增加了参与 GNSO 政策制定的利益主体的数量和多样性,因此需要按时执行审查,以检查当前模式是否符合新一代利益主体的需求。
      • GNSO 结构未必能满足预计因 TLD 空间扩展而产生的新一批利益主体的需求。GNSO 审查将成为考量和解决该问题的重要工具。GNSO 审查必须解决所出现的不平衡的情况。
      • 上一次审查的实施花费了多年时间。一般而言,回应者强调需要最大程度缩短 GNSO 审查流程的时长,从而为整个 ICANN 机构群体提供更高效、反应更迅速和有效的 GNSO 审查。
      • ATRT 2 目前在评估政策制定流程以及战略规划流程中进行的工作均不能从实质上处理上述问题。

      公众意见征询流程的参与者包括品牌注册管理机构组、Google、互联网服务提供商和连接提供商社群、非营利性运营社群、非商业利益主体组织、知识产权社群、商业群体以及 ARI Registry Services。

      提议的办法不仅要积极响应结构群体强烈要求不再延迟的反馈,还要制定审查启动时间表,该时间表应考虑到工作的复杂性以及慎重规划的重要性,包括探索审查方法以及机构群体参与流程的方法。彻底且组织良好的审查应考虑到在当前所进行的工作收集的相关意见以及机构群体的各种意见,SIC 意识到这一点非常重要,于是结合来自机构群体的反馈对这些考虑进行了权衡。

      为了履行《章程》规定的理事会义务,即"定期审查各个支持组织、各个支持组织委员会的绩效和运作",SIC 建议认真开始计划下一次 GNSO 审查,从而为尽早在 2014 年开始的审查做好准备。

      机构审查的目的是决定 (i) 作为 ICANN 组织结构的一部分,该组织是否具有长期的目标,(ii) 如果有,那么对其结构或运作方式的任何更改是否有助于提高其效力。"考虑到环境的不断变化、参与的利益主体数量及其多样性的增加以及上一次 GNSO 审查总结的经验,SIC 认为要确保改进建议有用且可行,关键是要做好审查的规划工作。SIC 在制定和实施审查时间表时应考虑公众意见中明确表达的紧迫感,同时确保分配充裕的时间来进行规划工作。额外分配至机构群体磋商的时间将确保机构群体有充裕的时间就应如何执行第二次 GNSO 审查以便加强 ICANN 的问责制和透明度考虑和提供意见。

      预计不会影响 DNS 的安全性和稳定性。GNSO 审查开始时财政和资源将受影响。预计这些资源和费用将被分配到到审查开始和结束所在相关财年的 ICANN 预算中。

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

  2. 主要议程:

    1. 任命 2014 年提名委员会主席和候任主席

      鉴于 BGC 审核了 2014 年度提名委员会("NomCom")主席和候任主席候选人的意向书、会见了这些候选人以及考量了 2013 年度 NomCom 领导人全方位评估结果。

      鉴于 BGC 建议任命 Cheryl Langdon-Orr 为 2014 年度 NomCom 主席,Stéphane Van Gelder 为 2014 年度 NomCom 候任主席。

      兹发布第 2013.09.28.10 号决议:理事会在此任命 Cheryl Langdon-Orr 为 2014 年度提名委员会主席,Stéphane Van Gelder 为 2014 年度提名委员会候任主席。

      第 2013.09.28.10号决议的理由

      《ICANN 章程》要求理事会任命提名委员会 (NomCom) 主席和候任主席。如要查看第 VII 条第 2.1 款和第 2.2 款内容,请访问 http://www.icann.org/zh/general/bylaws.htm#VII。理事会已委托理事会管理委员会承担推荐理事会主席和候选主席供理事会批准的责任。关于 BGC 章程,请访问:http://www.icann.org/en/committees/board- governance/charter.htm。在提出建议之前,BGC 发布了征求意向书 (EOI) 的公告、审核了收到的意向书、与候选人进行了面谈,并且对 2013 年度 NomCom 领导人全方位评估进行了视察。理事会考虑并同意了 BGC 的建议。理事会还想感谢所有有意成为 NomCom 领导人并提交了意向书的人士。

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

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

    2. 处理新 gTLD 历史成本

      鉴于 ICANN 多年来在设计和准备启动新 gTLD 计划方面花费成本。

      鉴于 2007 年 10 月(GNSO 提出新 gTLD 计划建议的日期)因启动该计划而产生的成本("历史开发成本")要用一部分新 gTLD 计划申请费偿还给 ICANN。

      鉴于随着评估工作的推进,从 2012 年 7 月开始,历史开发成本逐步被计入该计划,且费用变得不可退还。

      鉴于理事会财务委员会建议将偿还到 ICANN 运营资金的历史开发成本金额转变成储备金。

      兹发布第 2013.09.28.11 号决议:理事会授权总裁兼首席执行官或其指定人员在合适时采取一切必要措施来将所有构成历史开发成本的金额(不管是已支付或有待日后偿还)从 ICANN 的运营资金转变为 ICANN 的储备金。

      第 2013.09.28.11号决议的理由

      在 2012 年 1 月启动该计划之前,ICANN 已在定义、设计和准备新 gTLD 计划的启动方面花费成本("历史开发成本")。(见附录 1)

      在设计计划时,历史开发成本取自 ICANN 的运营资金,并挪用新 gTLD 计划申请人支付的部分申请费进行偿还。为了确保收到足够的资金,从每个申请人的申请费中取 25,000 美元用于向 ICANN 偿还历史开发成本。25,000 美元的金额是通过将该计划的总开发成本历史估算值除以 500 个申请得出的。此外,据确认,ICANN 花费的通过部分申请费偿还的成本是指从 2007 年 10 月(有关新 gTLD 的 GNSO 政策建议大约在此日期提出)到 2012 年 1 月(启动该计划的日期)之间产生的成本。

      经过 ICANN 工作人员的估算,历史开发成本大约为 3250 万美元。该金额已于 2012 年 6 月在关于 2013 财年预算的演讲上进行了传达。现正制定其最终的详细文档以作审计并向机构群体发布。

      在受退款影响之前,已通过对实际收到的申请每个征收 25000 美元(25k * 1930 个申请,共计 4800 万美元)来偿还历史开发成本。4800 万美元(扣除退款)与约 3250 万美元之间的差额将作为该计划的净余额。

      随着评估工作的开展和申请费变为不可退还,历史开发成本的偿还金额从 2012 年 7 月开始不断计入新 gTLD 计划。

      从 2012 年 7 月到 2013 年 6 月计入新 gTLD 计划的约 1700 万美元的成本(含相应的 ICANN 收益)于 2013 年 8 月被转移至 ICANN 的运营账户。

      尽管一直以来都是将历史开发成本的偿还资金转移至 ICANN 的储备金,但这种做法从未通过理事会决议正规化。(见附录 1)待开始将现处于 ICANN 运营账户中的已偿还历史开发成本转移至储备金后,ICANN 实际上打算随着金额不断计入新 gTLD 计划账户而每季度转移一次到储备金。

      该决议将产生积极影响,明确 ICANN 资源的管理。这将对 ICANN 和所针对的机构群体产生财务影响。此项措施对域名系统 (DNS) 的安全性、稳定性和灵活性不会产生任何影响。

      该决议体现了组织管理职能,现阶段无需征询公众意见,但历史开发成本的处理性质和方法以及该成本被转移至储备金的这一事实已预先公布并征询公众意见。

    3. GNSO 利益主体组织和社群章程的修正流程提案

      鉴于《ICANN 章程》(第 X 条第 5.3 款)规定"每个 [GNSO] 利益主体 组织...及其每个关联的社群都应始终得到 ICANN 理事会的认可。"

      鉴于 GNSO 利益主体组织和社群必须在权衡需要理事会批准的同时,灵活更新、修改和制定其组织章程以反映机构群体变化。

      鉴于当前无程序供 GNSO 利益主体组织或社群据以向 ICANN 理事会申请批准修改其章程。

      鉴于 ICANN 理事会的机构改进委员会制定并推荐了一个流程供 GNSO 利益主体组织和社群据以修改其章程,而理事会则肩负并维持认可和验证这些 GNSO 组织的责任。

      鉴于已为机构群体提供审查和评论提议的流程的机会,并且已综合机构群体的建议对提议的流程进行了修改。

      兹发布第 2013.09.28.12 号决议:理事会批准机构改进委员会制定和推荐的流程,并指示 ICANN 工作人员将该流程告知各 GNSO 利益主体组织和社群的领导人,并在七个日历日内将批准的流程副本发布至 GNSO 网站。

      第 2013.09.28.12号决议的理由

      2009 年 7 月,为落实 GNSO 全面改进计划,ICANN 理事会批准了四家新 GNSO 利益主体组织的正式章程(请参阅 ICANN Board Resolution 2009.30.07.09)。

      《ICANN 章程》(第 X 条第 5.3 款)规定"每个利益主体组织...及其每个关联的社群都应始终得到 ICANN 理事会的认可。"由于 2009 年的原 GNSO 组织章程经过了机构群体和理事会成员之间的全面和严谨的磋商,因此正适合理事会审核并批准之后的章程修正。再者,理事会认为在根据《ICANN 章程》原则持续认可正式批准的 GNSO 组织结构时,审核由 GNSO 利益主体组织及其社群维护的 GNSO 章程修正是一项重要义务。

      理事会的机构改进委员会 (SIC) 制定了该流程,并向机构群体公布了提案,以供审查和评论。理事会批准的最终版本反映了在对机构群体就工作人员通知的时间以及理事会审核机构群体章程修正的时间表和流程提出的有用反馈进行考量后,对原 SIC 提案进行的调整。

      此项举措不会对 ICANN 资源造成直接或实质影响。在某些情况下,此举措将需要机构群体投入额外工作、工作人员给予支持以及理事会花时间进行审核,但这些工作应该不会持续很长时间,而且还会提高 ICANN 结构和管理流程的透明度和最终效率。

      此项举措预计不会对 DNS 的安全性、稳定性或灵活性造成任何影响。

      文档/背景链接:机构群体公众意见论坛链接。

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

    4. 根据 AoC 审查对新 gTLD 计划的竞争、消费者信任和消费者选择衡量标准进行澄清

      鉴于在 2013 年 7 月 18 日,ICANN 理事会指示首席执行官启动成立竞争、消费者信任和消费者选择 (CCT) 审核小组的流程,以推进对采纳 GNSO 委员会和 ALAC 建议以及分析 CCT 审核可用的其他潜在衡量标准的可行性、效用和成本效益而进行的初步工作。

      鉴于理事会希望澄清其第 2013.07.18.06 和 2013.07.18.07 号决议,确认并非现在就开始实际的 CCT 审查,而是批准供挑选的竞争、消费者信任和消费者实施咨询小组。日后在根据《义务确认书》(AoC) 中规定的时间表开始 CCT 审查时,将从该咨询小组中选派人员执行 CCT 审查。

       兹发布第 2013.09.28.13 号决议:理事会指示首席执行官在成立未来的 AoC 竞争、消费者信任和消费者选择审核小组之前,先成立志愿者小组(竞争、消费者信任和消费者选择实施咨询小组),其目的是:(i) 评估采纳 GNSO 委员会和 ALAC 建议的可行性、效用和成本效益,并上报理事会;(ii) 评估其他意见,包括评估之前轮次的新 gTLD(2000 年、2004 年)所用衡量标准的相关历史数据;(iii) 与 GNSO、ALAC 和工作人员齐心协力就衡量标准达成一致意见;以及 (iv) 提议一套衡量标准,交由 ICANN 编纂,以供未来的 AoC 审核小组用于检查新 gTLD 计划。

      兹发布第 2013.09.28.14 号决议:第 2013.07.18.06 和 2013.07.18.07 号决议中建议在 AoC 规定的时间之前开始 CCT 审查的部分已被取消。

      第 2013.09.28.13 – 2013.09.28.14号决议的理由

      理事会的决议希望澄清之前有关评估衡量标准的决议,该衡量标准由机构群体提议,供将来用于按照《义务确认书》(AoC) 审查新 gTLD 在竞争、消费者信任和消费者选择领域中的影响。

      理事会的决议呼吁总裁兼首席执行官在成立未来的竞争、消费者信任和消费者选择审核小组之前,先成立一个负责提供实施建议的志愿者小组,负责:评估并报告实施机构群体建议的各种消费者衡量标准的可行性、效用和成本效益;评估其他意见,包括评估之前轮次的新 gTLD(2000 年、2004 年)所用衡量标准的相关历史数据;与 GNSO 和 ALAC 齐心协力就衡量标准达成一致意见;最终提出一系列衡量标准,供理事会批准,从而进行收集并自行酌情用于将来根据 AoC 执行的审查。如果在与 GNSO 和 ALAC 讨论此事后,竞争、消费者信任和消费者选择实施咨询小组最终建议不用 GNSO 委员会和/或 ALAC 提议的衡量标准,咨询小组将向理事会做出解释。

      该项工作即将开始,包括鼓动机构群体和 ICANN 参与其中、评估 GNSO 委员会和 ALAC 提议的衡量标准并予以报告,以及向 ICANN 推荐要收集的衡量标准以备将来用于新 gTLD 计划审查。

      当新 gTLD 运营满一年时,将根据 AoC 执行审查,其包括评估 gTLD 的引入和扩展对竞争、消费者信任和消费者选择的促进程度。开始该审查的时机尚未成熟。现在,理事会呼吁开始实施工作是为了方便在时机合适时开展 AoC 审查工作。

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


1 需要说明的是,根据过期域名删除政策 (EDDP),此类锁定不应阻止根据 UDRP 程序续用域名。

2 该检查是 UDRP 提供商进行的初步检查,旨在确保不涉及虚假投诉。该检查不得与 UDRP 描述的行政合规性检查相混淆,后者根据本提案的第 4 步进行。

3 适用于在 ICANN 的隐私/代理委任计划定案后的委任隐私/代理提供商。

4 工作日指需要采取行动的实体所在辖区的工作日,该实体在此指注册服务商。

5 披露的资料只能包含委任/附属的隐私/代理提供商记录在案的资料。

6 为示澄清,这包括任何转让到隐私或代理服务的行为,但披露下段中规定的代理客户资料除外。

7 UDRP 提供商将向注册服务商发送验证请求,以便核实各种信息,包括具名的被投诉人是争议域名的实际注册人、注册协议的语言,以及被投诉人的详细联系信息。

8 这一验证请求与注册服务商向提供商提供所请求事项的验证的要求有关。

9  建议对 UDRP 规则(当前描述的是"日历"日)进行这一更改旨在保证其与锁定信息的 2 个工作日要求相符,否则可能出现 2 个工作日长于 3 个日历日的情况,使得 UDRP 提供商不能在指定时间段内完成行政合规性检查。

10 增加此项建议的理由是解决公众意见论坛期间所表达的顾虑,即由于提议不再要求投诉人在提交投诉书时通知被投诉人的更改,因此减少了非正式响应时间,并在需要时确保实际需要额外四天的相关被投诉人不必担心成本问题,也不会影响 UDRP 的整体时间表。

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