Skip to main content
Resources

ICANN 理事会通过的决议 | ICANN 理事会特别会议

本页面还提供其他语种:

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

This document has been translated into multiple languages for information only. The original and authoritative text (in English) may be found at: http://www.icann.org/en/minutes/resolutions-25jan11-en.htm

*说明:理事会行动理由草案会在相关决议下提供。理由草案只有在理事会会议记录获得批准后才会成为最终版本。

  1. 认可议程
    1. 批准 2010 年 12 月 8 日的 ICANN 理事会特别会议记录
    2. 批准 2010 年 12 月 10 日的 ICANN 理事会例行会议记录
    3. 批准 2010 年 12 月 10 日的 ICANN 理事会组织会议记录
    4. 批准财务委员会章程修订版
    5. 来自 SSAC – 任命 SSAC 主席
    6. 来自 SSAC – 感谢即将离任的 SSAC 成员 – Christophe Reverd
    7. 来自 SSAC – 感谢即将离任的 SSAC 成员兼副主席 – Ray Plzak
    8. 来自 SSAC – 感谢即将离任的 SSAC 主席 – Steve Crocker
    9. 批准跟进 IPv4 耗尽后的全球政策流程
    10. 批准 RSSAC 审核实施计划
    11. 批准为提名委员会设立非投票当选主席的章程修正提案
    12. 感谢 2010 年提名委员会
    13. 批准重新授权表示布基纳法索的域名 .BF
    14. 批准重新授权表示刚果民主共和国的域名 .CD
    15. 批准重新授权表示阿拉伯叙利亚共和国的域名 .SY
    16. 批准授权以韩文表示大韩民国的域名 .한국 ("Hanguk")
    17. 批准授权以中文和泰米尔 文 表示新加坡的域名 .新加坡 ("Singapore") 和 .சிங்கப்பூர் ("Singapore")
    18. 批准授权以阿拉伯文表示阿拉伯叙利亚共和国的域名 .سورية ("Sourya")
    19. 批准授权以不同语言表示印度的七个顶级域名

主要议程

  1. 批准修改支持组织及网络普通用户群体推选的理事会成员任期结束日期的章程修正提案
  2. 批准 Telnic 提出的除单字母标签外发行仅数字字符串的 RSEP 申请
  3. 理由文档
    1. 经济研究 – 采纳理由
    2. 交叉所有权 - 采纳理由
  4. 理事会 /GAC 意见征询
    1. 新 gTLD
    2. ICM
  5. 关于 AOC 审核 , 包括 ATRT 建议的报告 – 后续计划

 

  1. 认可议程

    决议: 特此批准本认可议程中的以下决议:

    1. 批准 2010 年 12 月 8 日的 ICANN 理事会特别会议记录

      第 2011.01.25.01 号决议: 理事会特此批准 2010 年 12 月 8 日的 ICANN 理事会特别会议记录。

    2. 批准 2010 年 12 月 10 日的 ICANN 理事会例行会议记录

      第 2011.01.25.02 号决议: 理事会特此批准 2010 年 12 月 10 日的 ICANN 理事会例行会议记录。

    3. 批准 2010 年 12 月 10 日的 ICANN 理事会组织会议记录

      第 2011.01.25.03 号决议: 理事会特此批准 2010 年 12 月 10 日的 ICANN 理事会组织会议记录。

    4. 批准财务委员会章程修订版

      理事会财务委员会 (BFC) 目前遵循的是 2000 年通过的章程,发布在 http://www.icann.org/en/committees/finance/

      BFC 的一项职责是审核其运作,然后提出合适的更新或改进建议; 2010 年 12 月 5 日, BFC 批准了其章程修订版,以更如实地反映 BFC 的目前运作。该章程修订版还原样引入了理事会管理委员会之前批准通过的《理事会管理委员会章程》的标准文本。请参见 http://www.icann.org/en/minutes/resolutions-06mar09.htm#10

      第 2011.01.25.04 号决议: 批准理事会财务委员会章程修订版。

      2011.01.25.04 号决议理由

      此次批准修订版理事会财务委员会 (BFC) 章程是合适的,因为修订版比前一版更如实地反映了 BFC 目前的运作。该修订版还符合理事会管理委员会批准的所有其他章程的最新修订版。此外,章程修订版还反映了 BFC 与 ICANN 2011 年的规模和覆盖范围相关的工作活动,并指出 BFC 的运作符合最佳做法。在制定章程修订版期间,理事会审核了 ICANN BFC 的最佳做法及实际运作,并认为这两方面对于批准章程修订版十分重要。

      BFC 章程修订版的批准预计会产生积极的公共影响,因为该修订版提高了委员会的责任性和透明性,并且如实反映了 BFC 目前的工作活动和最佳做法。修订 BFC 章程对于 ICANN 或机构群体不会产生财务影响。通过修订其章程而确认 BFC 的职责不会对 DNS 的系统安全、稳定性和灵活性造成任何影响。

    5. 来自 SSAC - 任命 SSAC 主席

      ICANN 章程中第 XI 条第 2 款的 2 小节对安全与稳定咨询委员会 (SSAC) 做出了规定。

      ICANN 章程中第 XI 条第 2 款的 2 小节规定理事会应负责任命 SSAC 的主席和成员。

      Steve Crocker 于 2010 年 12 月 10 日宣布自己将辞去 SSAC 主席一职,但将留任到 SSAC 推举出新主席并获得理事会批准任命。

      Ray Plzak 已于 2010 年 12 月 22 日辞去 SSAC 副主席职务。

      SSAC 自 2010 年 12 月 10 日开始从委员会成员中推选主席和副主席,选举于 2011 年 1 月 7 日结束。

      委员会推举 Patrik Fältström 出任主席,推举 James Galvin 出任副主席。

      第 2011.01.25.05 号决议: 理事会接受了 SSAC 的推选建议,任命 Patrik Fältström 担任 SSAC 主席,并对 Patrik Fältström 和 James Galvin 各自出任新的要职表达了最良好的祝愿。

    6. 来自 SSAC - 感谢即将离任的 SSAC 成员 - Christophe Reverd

      2009 年 6 月 26 日, Christophe Reverd 被任命为 ICANN 安全与稳定咨询委员会成员。

      ICANN 积极肯定并真诚感谢 Christophe Reverd 在担任安全与稳定咨询委员会成员期间为机构群体提供的服务。

      第 2011.01.25.06 号决议: 理事会谨对 Christophe Reverd 在担任安全与稳定咨询委员会成员期间为 ICANN 提供的服务致以诚挚的谢意,并真诚祝愿 Christophe Reverd 将来的事业顺利如意。

    7. 来自 SSAC - 感谢即将离任的 SSAC 成员兼副主席 - Ray Plzak

      2002 年 5 月 17 日, Ray Plzak 被任命为 ICANN 安全与稳定咨询委员会成员。

      ICANN 积极肯定并真诚感谢 Ray Plzak 在担任安全与稳定咨询委员会成员兼副主席期间为机构群体提供的服务。

      第 2011.01.25.07 号决议: 理事会谨对 Ray Plzak 在担任安全与稳定咨询委员会成员兼副主席期间为 ICANN 提供的服务致以诚挚的谢意,并真诚祝愿 Ray Plzak 将来的事业顺利如意。

    8. 来自 SSAC - 感谢即将离任的 SSAC 主席 - Steve Crocker

      2002 年 3 月 14 日, Stephen Crocker 博士被任命为 ICAN 安全与稳定咨询委员会主席。

      Crocker 博士在担任 SSAC 主席期间,以其卓越的才干和全心的投入,出色地完成了使命。

      Crocker 博士带领建立了 SSAC 运作的结构和工作内容,并引领委员会成功完成了重大的里程碑事件,如 SiteFinder 和根区域升级。

      Crocker 博士扩充了 SSAC 的成员构成,吸纳了多种领域的主题专家,从而既拓展了委员会的地理多样性,也提升了人员配备的广度。

      在 Crocker 博士的引领下, SSAC 通过了其第一次外部综合审核,确保了各项建议的及时实施。

      在 Steve Crocker 的努力下,安全与稳定咨询委员会完成了从概念阶段到出色实际运作的大转变,无论是在委员会内部还是在 ICANN 群体都提高了自己的声誉。

      Crocker 博士于 2010 年 12 月 10 日宣布自己将辞去 SSAC 主席一职,但将留任到 SSAC 推举出新主席并获得理事会批准任命。

      SSAC 自 2010 年 12 月 10 日开始从委员会成员中推选主席和副主席,选举于 2011 年 1 月 7 日结束。

      委员会推举 Patrik Fältström 出任主席,推举 James Galvin 出任副主席。

      2011 年 1 月 25 日,理事会任命 Patrik Fältström 为 SSAC 新任主席。

      第 2011.01.25.08 号决议: 理事会谨对 Crocker 博士在担任安全与稳定咨询委员会主席期间为 ICANN 提供的不懈服务与全心投入致以最诚挚的谢意,并真诚祝愿 Crocker 博士将来的事业顺利如意。

    9. 批准跟进 IPv4 耗尽后的全球政策流程

      理事会对 ASO 地址委员会根据 ASO 谅解备忘录提交供审批的全球互联网号码资源政策的审核程序 中规定“当负责联络地址分配群体的 ICANN 工作人员根据 ASO 谅解备忘录的全球政策制定流程中的步骤 1 (附件 A ,第 1 条)了解到发生了属于 ASO 谅解备忘录范围内的全球政策制定时,应该就此通知 ICANN 理事会 。 理事会决定,在适当时机, ICANN 工作人员应该跟进这种政策制定,并指示 ICANN CEO 委任负责工作人员。受委任负责此项工作的 ICANN 工作人员应该通知所有 ICANN 支持组织和咨询委员会,并且应该建立一个 ICANN 网页发布最新信息,还应该拟具一份背景报告,提供关于此全球政策制定的最新信息。若理事会要求,应该向其提供此背景报告。”

      ICANN 工作人员已通知理事会,一项题为 "IANA 关于 IPv4 耗尽后 IPv4 地址分配的全球政策提议”的政策提议正在制定之中,现已进入各个地区互联网注册机构 (RIR) 的初步讨论阶段,并被 ASO 地址委员会认可为有效的全球政策提议。

      该项提议被视为属于 ICANN 与 ASO 之间达成的谅解备忘录范围的全球政策制定。

      第 2011.01.25.09 号决议: 理事会要求 "IANA 关于 IPv4 耗尽后 IPv4 地址分配的全球政策提议”的制定应由 ICANN 工作人员根据理事会关于此类政策提议的审核程序进行跟进,并指示 ICANN CEO 委任负责此项工作的工作人员。

      2011.01.25.09 号决议理由

      此项全球政策提议已进入在各个地区互联网注册管理机构中展开讨 论的阶段, 现在开始拟具和发布关于提议状态的背景报告的时机已经成熟。指导工作人员开展必要的跟进工作,是 ICANN 与 ASO 的谅解备忘录中以及理事会全球互联网号码资源政策审核程序中规定的一项 ICANN 衍生职责。

      指导 ICANN 工作人员跟进提议的工作只会产生很小的预算影响,因为工作人员已经分配给 ASO ,使得这一阶段的提议跟进只需要有限的工作量。如果提议获得批准,后续的实施可能会对预算、公共和安全 / 稳定性相关问题产生更多影响,但现在并不是评估这些影响的成熟时机。要求工作人员在此阶段跟进还有利于在 ASO 要求审批提议之前做好前期准备工作。

    10. 批准 RSSAC 审核实施计划

      2010 年 8 月 5 日,理事会决议接受 RSSAC 审核工作组的最终报告,并指示机构改进委员会 (SIC) “提交一套建议的举措,在 2010 年 10 月召开的理事会会议上进行审批,以实施该工作组最终报告中提出的结论和建议”,参见 http://www.icann.org/en/minutes/resolutions-05aug10-en.htm#2.f

      负责为组织审核提供支持的 ICANN 工作人员在 "RSSAC 审核工作组最终报告:实施步骤”文档中( 2010 年 12 月发布)提议了一套举措,以实施工作组提出的建议并将其提交给 SIC 。

      SIC 认为提议的举措很充分,并建议工作人员与 SIC 协作,根据提议的实施步骤最终确定一份实施计划,并将最终实施计划提交给理事会进行讨论审批。

      第 2011.01.25.10 号决议: 理事会批准了 SIC 提交的 "RSSAC 审核工作组最终报告:实施步骤”,并指示 SIC 与工作人员协作,向理事会提交一份最终实施计划,以实施 RSSAC 审核工作组最终报告中提出的结论和建议。

      2011.01.25.10 号决议理由

      应理事会 2010 年 8 月 5 日关于提交此提议的决议要求,向理事会提交了提议的实施步骤。实施步骤旨在实现审核工作组最终报告中提出的建议。最终报告草案已发布征询公众意见,没有收到意见或建议,也没有收到关于如果采纳建议会产生负面影响的意见。此外,采纳 RSSAC 审核工作组最终报告的实施计划将会创造一个有利条件,以委任一位专门的工作人员,促进 ICANN 与根服务器运营机构在 RSSAC 结构框架内的协作与沟通。

      指导制定最终实施计划会产生稍许预算影响,因为需要分配额外工作人员资源来支持 ICANN 的组织审核。最终实施步骤的确定预计由现有人员资源来完成。实施工作的进一步影响根据实际情况确定。

    11. 批准为提名委员会设立非投票当选主席的章程修正提案

      ICANN 章程中第 VII 条第 2 款和第 3 款规定了提名委员会 (NomCom) 的构成和 NomCom 成员的任期。

      在 2010 年 1 月 29 日发布的最终报告 http://www.icann.org/zh/reviews/nomcom/nomcom-review-finalization-wg-final-report-29jan10-zh.pdf [PDF, 461 KB] 中, NomCom 终审工作组建议提前一年选举 NomCom 主席,这需要修订 ICANN 章程的第 VII 条第 2 款和第 3 款,参见 http://www.icann.org/en/general/bylaws.htm#VII

      2010 年 3 月 12 日,理事会收到 NomCom 审核最终报告,并指示机构改进委员会 (SIC) 确定实施报告中建议的必要举措,参见 http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#1.6

      SIC 在其 2010 年 10 月 14 日召开的会议上,提议应该修订 ICANN 章程,以实施 NomCom 终审工作组关于提前一年选举 NomCom 主席的建议,同时强调相关的章程修订必须容许适当的灵活性,允许理事会审核。

      理事会在其 2010 年 10 月 28 日召开的会议上决定应发布章程修正提案以征询公众意见。

      章程修正提案发布在 http://www.icann.org/en/general/proposed-bylaws-revision-vii-10nov10-en.pdf [PDF, 64 KB] ,公众意见征询期从 2010 年 11 月 10 日开始到 12 月 10 日结束,在此期间没有收到任何建议和意见。

      第 2011.01.25.11 号决议: 理事会批准章程修正提案,并指示工作人员与机构改进委员会协作,为新条款对 2013 年提名委员会生效做好实施准备工作。

      2011.01.25.11 号决议理由

      章程修正提案旨在实施 NomCom 终审工作组提出的提前一年任命 NomCom 主席的建议,同时保留适当的灵活性,允许理事会审核主席候选人。

      到目前为止,尚未收到关于此项修正不会对提名委员会及其流程产生积极影响的任何公众意见。此修正产生的预算影响可以忽略,因为从主席身边无投票权的顾问到当选主席的转变,并不会导致需要通过提名委员会预算支持的提名委员会成员人数的变化。

    12. 感谢 2010 年提名委员会

      2009 年 8 月 27 日, ICANN 任命 Wolfgang Kleinwächter 担任提名委员会主席。

      2010 年提名委员会由来自每个 ICANN 社群和咨询机构的代表组成。

      第 2011.01.25.12 号决议: ICANN 理事会谨对 Wolfgang Kleinwächter 与 2010 年提名委员会全体成员的全心投入、辛勤努力和工作成果致以深深的谢意。

    13. 批准重新授权表示布基纳法索的域名 .BF

      BF 是分配给 布基纳法索 的 ISO 3166-1 双字母国家或地区代码。

      ICANN 收到了将 .BF 重新授权给 Autorité de Régulation des Communications Electroniques 的申请。

      ICANN 在审核此申请后,认为提议的重新授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.13 号决议: 批准将域名 .BF 重新授权给 Autoritéde Régulation des Communications Electroniques 的提议。

      2011.01.25.13 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    14. 批准重新授权表示刚果民主共和国的域名 .CD

      CD 表示分配给刚果民主共和国的 ISO 3166-1 双字母国家或地区代码;

      ICANN 收到了将 .CD 重新授权给 Office Congolais des Postes et Telecommunications 的申请;

      ICANN 在审核此申请后,认为提议的重新授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.14 号决议: 批准将域名 .CD 重新授权给 Office Congolais des Postes et Telecommunications 的提议。

      2011.01.25.14 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。

      此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    15. 批准重新授权表示阿拉伯叙利亚共和国的域名 .SY

      SY 是分配给阿拉伯叙利亚共和国的 ISO 3166-1 双字母国家或地区代码。

      ICANN 收到了将 .SY 重新授权给 National Agency for Network Services 的申请;

      ICANN 在审核此申请后,认为提议的重新授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.15 号决议: 批准将域名 .SY 重新授权给 National Agency for Network Services 的提议。

      2011.01.25.15 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    16. 批准授权以韩语表示大韩民国的域名 .한국 ("Hanguk")

      한국 ("Hanguk") 的编码为 "xn--3e0b707e",被视为是通过 IDN 快速通道流程表示大韩民国的合适字符串。

      ICANN 收到了将 .한국 授权给韩国互联网与安全局 ( Korea Internet & Security Agency) 的申请。

      ICANN 在审核此申请后,认为提议的授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.16 号决议: 批准将域名 .한국 重新授权给韩国互联网与安全局 (Korea Internet & Security Agency) 的提议。

      2011.01.25.16 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。

      此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    17. 批准授权以中文和泰米尔语表示新加坡的域名 .新加坡 ("Singapore") 和 .சிங்கப்பூர் ("Singapore")

      目前 ISO 3166-1 标准中列出的是 Singapore ;

      新加坡 ("Singapore") 的编码为 "xn--yfro4i67o", சிங்கப்பூர் ("Singapore") 的编码为 "xn--clchc0ea0b2g2a9gcd",被视为是通过 IDN 快速通道流程表示新加坡的两个合适字符串;

      ICANN 收到了将 .新加坡 和 .சிங்கப்பூர் 授权给新加坡网络信息中心 (Singapore Network Information Centre Pte Ltd) 的申请。

      ICANN 在审核此申请后,认为提议的授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.17 号决议: 批准将上述顶级域名授权给新加坡网络信息中心 (Singapore Network Information Centre Pte Ltd) 的提议。

      2011.01.25.17 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。

      此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    18. 批准授权以阿拉伯语表示阿拉伯叙利亚共和国的域名 .سورية ("Sourya")

      目前 ISO 3166-1 标准中列出的是 Syrian Arab Republic ;

      .سورية ("Sourya") 的编码为 "xn--ogbpf8fl",被视为是通过 IDN 快速通道流程表示阿拉伯叙利亚共和国的合适字符串。

      ICANN 收到了将 .سورية 授权给国家网络服务局 (National Agency for Network Services) 的申请;

      ICANN 在审核此申请后,认为提议的授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.18 号决议: 批准将域名 .سورية ("Sourya") 授权给国家网络服务局 (National Agency for Network Services) 的提议。

      2011.01.25.18 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。

      此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

    19. 批准授权以不同语言表示印度的七个顶级域名

      目前 ISO 3166-1 标准中列出的是 India ;

      भारत ("Bharat") 的编码为 "xn--h2brj9c", بھارت "Bharat") 的编码为 "xn--mgbbh1a71e", భారత్ ("Bharat") 的编码为 "xn--fpcrj9c3d", ભારત ("Bharat") 的编码为 "xn--gecrj9c", ਭਾਰਤ ("Bharat") 的编码为 "xn--s9brj9c", இந்தியா ("Bharat") 的编码为 "xn--xkc2dl3a5ee0h", ভারত ("Bharat") 的编码为 "xn--45brj9c" ;这些被视为是通过 IDN 快速通道流程表示印度的七个合适字符串;

      ICANN 收到了将上述七个字符串作为顶级域名授权给印度国家互联网交换 (National Internet Exchange of India) 的申请;

      ICANN 在审核此申请后,认为提议的授权会符合当地和全球互联网群体的利益。

      第 2011.01.25.19 号决议: 批准将上述七个顶级域名授权给印度国家互联网交换 (National Internet Exchange of India) 的提议。

      2011.01.25.19 号决议理由

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

      如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能(尤其是 DNS 根区域)相关的请求的承诺, ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。

      讨论的提议是什么?

      提议是批准向 IANA 提交的一项申请,请求变更或指定某个国家或地区代码顶级域名的主办组织(也称为管理者或受托者)。

      根据现行做法,在这个多步骤流程中,一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。

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

      在评估授权申请期间, ICANN 工作人员咨询了申请人、当前运营商(如适用),以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例, ICANN 尚未对此问题进行公开的咨询。

      机构群体提出了哪些担心或问题?

      所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理,将在 IANA 网站 http://www.iana.org/ 上发布该报告,通常是在理事会作出决定后的 1 到 2 个月后。

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

      理事会依据各种公众利益标准来评估申请。

      此类标准包括:确保国家或地区代码合法(例如在 ISO 3166-1 标准中列出);确保当地互联网群体支持提议的管理者;确保提议的运营商在运作及技术方面有足够能力;确保提议的管理者以当地为基础并且受当地法律制约;确保提议的管理者秉承公平的运营原则;确保当发生运营方变更时存在一个适当的计划,能够保持域名的持续稳定性;并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间,会要求申请人提供各种材料来支持上述各方面。

      来自这些材料及其他工作人员研究的相关信息结果将提交给理事会,并在实施获批申请后在一份公开报告中发布这些信息。

      理事会认为哪些因素很重要?

      理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。

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

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

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

      管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责,授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责, ICANN 负责确保运营商总部位于该国,并有相应的机制允许当地互联网群体适当监督域名的持续运营。

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

      对于国家或地区代码顶级域名授权, ICANN 倾向于只批准此类申请:令人满意地解决了有合理理由担心的问题,并且提议的新管理者展示出足够高的运营和技术能力水平,使这些问题不会成为担心的问题。

主要议程

  1. 批准修改支持组织及网络普通用户群体推选的理事会成员任期结束日期的章程修正提案

    该章程目前规定,即将就任的 ICANN 理事会成员如果并非由提名委员会 (NomCom) 任命,则在上一年的年度全体会议 (AGM) 之后应在理事会任职满六个月。

    上一年的年度全体会议之后的六个月通常介于 ICANN 国际公开会议(“会议”)之间。

    理事会审核工作组 (BRWG) 建议 [PDF, 299 KB]: 并非由提名委员会任命的理事会成员的任职应在年中公开会议期间履行,以方便理事会成员的顺利过渡。

    理事会管理委员会 ("BGC") 考虑到此问题,同意 BRWG 提出的理由,但是提出由于年中公开会议有时可能不会召开,因此建议对 BRWG 的提议进行 修订,以便让新理事及时就任。

    反映 BRWG 建议的章程修正提案发布在 http://www.icann.org/en/public-comment/public-comment-201012-en.htm#bylaws-amend-article-vi8 中,进行为期两个月( 2010 年 11 月 8 日至 2011 年 1 月 8 日)的公众意见征询。

    在此公众意见征询期内,只收到了一条公众评论,表示支持修正提案。

    第 2011.01.25.20 号决议: 理事会批准必要的章程修正提案,旨在促进实现支持组织或网络普通用户群体推选的理事会成员的过渡变更。

    2011.01.25.20 号决议理由

    在 ICANN 理事会的 Boston Consulting Group (BCG) 独立审核了章程修正提案后 ( http://www.icann-ombudsman.com/en/reviews/board/report-02nov08-en.pdf [PDF, 921 KB] ) ,成立了一个理事会审核工作组 (BRWG) ,旨在帮助确定关于 BCG 建议的实施可行性。 BRWG 在召开了多次研讨会议、通过电子邮件进行大量沟通并进行了文件分析之后,于 2010 年 1 月发布了其最终报告 ( http://www.icann.org/zh/reviews/board/board-review-final-26jan10-zh.pdf [PDF, 299 KB] ) 。理事会考虑的一项 BRWG 建议是,在 ICANN 中期会议上使并非提名委员会推选的所有理事会成员就职。理 事会相信,在针对可能不召开中期会议的情况而进行稍许修改后, BRWG 的建议就很合理了,有助于确保理事会成员的顺利过渡。 从机构群体收到的唯一一条评论来自 ALAC ,表示支持章程修正提案。( 请参见 http://forum.icann.org/lists/bylaws-amend-article-vi8/msg00000.html “关于理事会成员任期过渡的章程修正提案符合 ALAC 关于过渡的原则。因此 ALAC 对这些修正表示欢迎和支持”。)

    理事会认为这些修正将产生积极的公众影响,因为通常新任理事会成员将在会议结束时就职,从而允许即将离任的理事会成员在该次会议结束时结束其任期。通过设立过渡期,可以比在两次理事会会议之间变更任期更顺利地实现过渡。即将离任的理事会成员将能够完成工作周期,即简要了解然后解决有待于在下一次会议上讨论和决定的问题。这样,新任理事会成员就能够在任期开始时从头开始处理后续问题。

    理事会的此项决策可能对 ICANN 产生些许的财务影响,因为需要支付即将离任和继任的理事会成员参加过渡会议的差旅住宿费用。不过,根据目前的组织架构,需要为其支付额外费用的理事会成员不会超过四位,通常更少。需要的额外差旅费用可能额度不太可能对预算或机构群体产生影响。理事会认为这不会对 DNS 的系统安全性、稳定性和灵活性产生影响。

  2. 批准 Telnic 提出的除单字符标签外发行全数字字符串的 RSEP 申请

    Telnic 根据 ICANN 注册管理机构服务评估政策提交了一份申请,请求修正 .TEL 注册管理机构协议,以允许在 .TEL 中分配全数字(单位数字除外)域名。

    .TEL 是目前仅有的两个不能分配全数字域名的 gTLD 之一。

    ICANN 在依据注册管理机构服务评估政策,将该 .TEL 注册管理机构协议修正提案作为一项新注册管理机构服务进行评估后,没有发现任何安全性、稳定性或竞争问题,因此发布了该提案以供公众提出意见和理事会讨论(请参见 http://www.icann.org/en/announcements/announcement-14oct10-en.htm )。

    在公众意见征询期内以及由 ICANN 提出的潜在问题已经由 Telnic 的回应得到妥善解决。

    批准此项提议将是对注册人在 .TEL 中注册域名时可用选项的补充。

    第 2011.01.25.21 号决议: 批准旨在允许在 .TEL 中分配全数字(单位数字除外)域名的修正提案,并授权总裁和总顾问适当地执行举措来实施此修正案。

    2011.01.25.21 号决议理由

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

    2010 年 10 月 8 日, Telnic 根据 ICANN 注册管理机构服务评估政策提交了一份申请,请求修正 .TEL 注册管理机构协议,以允许在 .TEL 中分配全数字(单位数字除外)域名。 ICANN 建议 Telnic 应修订附录 6 “保留名称的安排”和附录 S “章程”以便实施新服务。 ICANN 认为该修正是对注册管理机构协议的一项重大修改,因此,必须由理事会进行审批。

    讨论的提议是什么?

    理事会讨论是否批准提议的修正,即允许在 .TEL 中分配全数字(单位数字除外)域名。

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

    该修正提案从 2010 年 10 月 14 日至 2010 年 11 月 13 日面向公众征询意见;共收到四条意见和评论,一条表示支持,一条未涉及到提案的实质,但提出了改进建议,还有一条提出了一个可能的问题,最后一条是来自 Telnic 的回应。 ICANN 要求 Telnic 解决公众意见论坛中以及由 ICANN 提出的问题,为此 Telnic 和 .TEL 的委托决策机构“ IPAG ”针对每个问题向 ICANN 提交了一封信函。

    机构群体提出了哪些担心或问题?

    在公众意见论坛中有人提出了以下问题: 1) 提议是否可能构成对 TLD 的根本性改变;由此 2) 是否跟进了委托的决策机构。

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

    讨论修正提案时,理事会审核了下列材料: Telnic 提交的关于新注册机构服务的申请 < http://www.icann.org/en/registries/rsep/telnic-request-08oct10-en.pdf > [PDF, 33 KB] ;理事会决议的修正提案主题 < http://www.icann.org/en/tlds/agreements/tel/proposed-tel-amendment-2-14oct10-en.pdf > [PDF, 65 KB] ;与该修正提案相关的意见和评论 < http://forum.icann.org/lists/tel-numeric-only-domains/ > ; .TEL 委托的 IPAG 提交的旨在解决所提问题的信函 < http://www.icann.org/en/registries/rsep/conroy-to-pritz-25nov10-en.pdf > [PDF, 644 KB] ;以及 Telnic 提交的旨在解决所提问题的信函 < http://www.icann.org/en/registries/rsep/mahdavi-to-schwartz-07jan11-en.pdf > [PDF, 80 KB] 。

    理事会认为哪些因素很重要?

    1. ICANN 依据 RSEP 对提议的服务进行了阈值安全性、稳定性和竞争审核,并未发现任何严重问题。全数字域名已经在 14 个 gTLD 和几个 ccTLD 中使用多年,没有对互联网的安全性或稳定性造成不利影响。从纯技术角度讲,哪些 TLD 允许使用全数字域名并无差别,因此该提议不会带来任何新问题。 ICANN 建议 Telnic 应修订附录 6 “保留名称的安排”和附录 S “章程”以便实施新服务。
    2. 该修正提案从 2010 年 10 月 14 日至 2010 年 11 月 13 日面向公众征询意见;共收到四条意见和评论,一条表示支持,一条未涉及到提案的实质,但提出了改进建议,还有一条提出了一个可能的问题,最后一条是来自 Telnic 的回应。在意见征询期内没有收到关于是否应批准该修正提案的明确一致观点;每个人建议的途径均不同,并提出了上述某些问题。
    3. Tim Ruiz (注册商 GoDaddy.com, Inc. )认为该提案可能会从根本上改变 TLD 的目的。 Ruiz 进一步补充说, Telnic 承诺不允许全数字域名的二级注册是其申请的一个根本方面,也是为何 .TEL 被授予 Telnic 而不是 Pulver (当时另一个 .TEL sTLD 竞标方)的一个主要原因。他的结论是,如果要批准此申请,必须要求重新竞标 .TEL sTLD ,为其他机构提供竞争投标的机会。
    4. Khashayar Mahdavi 是 Telnic Limited ( .TEL 注册管理机构)的 CEO ,他针对 Tim Ruiz 的意见提交了一份回应函。他声称,该提案不会对 .TEL 的性质造成根本性改变,因为对于全数字字符串的限制与 .TEL 的性质无关,而是一种现行举措,旨在消除关于可能与 ENUM 发生冲突的最初担心。 Mahdavi 表示, .TEL 的目的,正如其章程中规定的,是为希望使用 TLD 在 DNS 中存储和发布其联系信息的用户群体提供服务。
    5. 应 ICANN 的要求, .TEL 的决策机构 IPAG 于 2010 年 11 月 25 日提交了一封包含更多信息的信函,解释了在制定此 RSEP 申请时所遵循的政策制定和审批流程。
    6. 在该信函中, IPAG 主席 Lawrence Conroy 解释了为何该提议不会带来 ENUM 技术问题; Conroy 是一位公认的 ENUM 领域专家。 Conroy 宣称“ 在此提议中,单位数字标签(例如 1.tel 或 4.tel )将会保留,而不是申请禁止的全数字标签(例如 3663.tel );这不是必要或有用的。通过阻止所有单位数字标签, ENUM 树的根不能直接放置在 .tel 中。 ENUM 不适用于多位数字标签。 Telnic 过去没有,现在也无意启动 ENUM 的替代方案,并且与 ICANN 之间有关于 .tel 此项规定的长期有效协议。 ”(此信函在附录中提供)。
    7. 应 ICANN 的要求, Telnic 在 2011 年 1 月 7 日提交的信函中,解释了为何他们相信该提案不会在 .TEL 中的全数字域名与可能被视为对应的电话号码之间造成混淆。 Telnic 强调说以前并未发生此类问题,并且有足够的工具可以解决实际用户混淆和 / 或误解的问题,而且其他 TLD 已经提供了此类域名而没有受到限制或带来问题。最后, Telnic 表示即使用户混淆问题确实会发生,他们委托的 IPAG 也有足够的资质能力,能够解决可能发生的任何问题。
    8. .TEL 是被禁止分配全数字域名的两个 gTLD 之一。通过批准该提案, .TEL 将在与市场中其他 gTLD 的竞争中处于更有利的位置,反之,这也会为注册人提供更多的选择。

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

    如果批准该修正提案,允许 .TEL 与其他 gTLD 一样提供同类服务,将使 gTLD 市场竞争氛围更强,而更重要的是允许注册人有更多的注册选择。

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

    批准此修正提案对于战略规划、运营计划、预算、机构群体或公众没有可预见的财务影响 / 后果。

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

    与该修正相关的服务提议依据注册管理机构服务评估政策经过了初步的安全性与稳定性审核。 ICANN 没有发现任何安全性、稳定性或竞争问题: http://www.icann.org/en/registries/rsep/arias-to-shadrunov-14oct10-en.pdf [PDF, 53 KB] 。

  3. 理由文档

    1. 经济分析 - 采纳理由

      2010 年 12 月 10 日,理事会认可要求进行经济分析这一全局性问题已通过全面的专家咨询和分析(包括 CRA 国际、 Dennis Carlton 、 Michael Katz 和 Greg Rosston 发表的报告)予以解决。 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#2

      2010 年 12 月 10 日,理事会确认对于经济分析的要求, ICANN 正在接收和审核公众意见,而理事会将考虑公众意见,包括 GAC 的建议,并指示工作人员做出修改 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#2

      所有经济分析都确认了继续开放域名空间的总体益处,包括鼓励创新、拓展选择以及营造一个更健康的竞争环境。

      在申请人指南草案后续版本中根据机构群体建议引入详细的规则和防护机制,是一种尽量减小此政策实施相关成本的可取方法,并可优化域名空间作为全球公共资源的使用。

      为了避免更多延迟造成机会成本,现在的工作重点应该是在 2 月份召开的理事会 -GAC 会议上以及 3 月份召开的硅谷会议上机构群体互动交流时,最终确定这些机制。

      CEO 应继续确保工作人员考虑公众关于新 gTLD 经济分析阶段 II 的意见,以及 GAC 关于要求进行经济分析的建议,并据此对最终版本申请人指南进行适当修订。

      CEO 将认真考察实施时机,并确保履行《义务确认书》中规定的 ICANN 义务:如果新的 gTLD 运营时间达到一年, ICANN 将组织一次审核,以评估 gTLD 的引入或扩展对促进竞争、消费者信任和消费者选择方面的影响程度,并检查以下两项的有效性 (a) 申请和评估流程,和 (b) 现有防护机制,以减少此类引入或扩展带来的问题。

      理事会考虑了做出此决策的理由,目前正在对其进行修订,如果提议获得批准,将在会议记录中发布这些理由。

      第 2011.01.25.22 号决议: 理事会不会在做出是否启动新 gTLD 计划决策之前委托进行关于新 gTLD 的任何进一步经济分析,因为理事会已认定这样做并不会更好地为其决策提供依据。

      2011.01.25.22 号决议理由

      根据理事会决议,在会议期间讨论的理由正在修订中,将在获得批准后发布在会议记录中。

    2. 交叉所有权 - 采纳理由

      在 2010 年 11 月 5 日,理事会通过了新 gTLD 计划中注册管理机构与注册服务商之间交叉所有权的相关问题决议。 http://www.icann.org/en/minutes/resolutions-05nov10-en.htm

      理事会已经审核并讨论了解释理事会决策的提议理由。

      第 2010.01.25.23 号决议: 理事会采纳提议的理由作为其关于新 gTLD 计划中注册管理机构与注册服务商之间的交叉所有权决策的理由。

      2010.01.25.23 号决议理由

      理事会会议期间讨论的理由目前正处于修订期间,将随会议的初步报告一起以草案形式发布,并在获得理事会批准后在会议记录中发布。

  4. 理事会 /GAC 意见征询

    1. 新 gTLD

      ICANN 理事会和 ICANN 政府咨询委员会 (GAC) 安排了比利时布鲁塞尔会议,时间为 2011 年 2 月 28 日到 3 月 1 日(下称“布鲁塞尔会议”),旨在讨论 GAC 提出的关于新 gTLD 计划的各种具体问题,如下所述(“主题”):

      • 异议程序,包括需要政府支付费用;
      • 审核敏感字符串的程序;
      • 根区域调整;
      • 市场及经济影响;
      • 注册管理机构与注册服务商分离;
      • 保护权利所有者和消费者保护问题;
      • 与政府的授权后争议;
      • 地理名称的使用和保护;
      • 申请人的合法资源;
      • 为所有利益主体提供机会,包括来自发展中国家或地区的利益主体;
      • 执法尽职调查建议,以根据布鲁塞尔公报修正《注册服务商委任协议》;以及
      • 需要提前警告申请人,告知提议的字符串是否会被视为引发争议或敏感问题(包括地理名称)。

      布鲁塞尔会议不是 ICANN 章程的第 XI 条第 2 款第 1(j) 段所规定的意见征询会议。

      理事会希望在预定于 2011 年 3 月 13-18 日召开的 ICANN 硅谷 / 旧金山 ("SV/SF") 会议上,启动章程规定的意见征询工作。

      理事会希望在 SV/SF 会议期间进行的章程规定的意见征询仅限于布鲁塞尔会议中讨论的主题。

      第 2011.01.25.24 号决议: ICANN 理事会特此决定,尽可能按照《最终申请人指南提案》中规定的形式,开始启动新 gTLD 计划。

      第 2011.01.25.25 号决议: 理事会特此决定,对于上述目前不符合 GAC 建议的主题采取措施。

      第 2011.01.25.26 号决议: ICANN 理事会特此启动 ICANN 章程第 XI 条第 2 款第 1(j) 段规定的意见征询,计划于 ICANN SV/SF 会议期间 2011 年 3 月 17 日周四开展。

      第 2011.01.25.27 号决议: 启动的上述章程规定的意见征询应仅限于布鲁塞尔会议上讨论的以下主题:理事会在会议期间或结束后没有改变其立场,并且仍然不符合 GAC 建议。

      2011.01.25.24 – 2011.01.25.27 号决议理由

      理事会及 GAC 都认为有必要针对与启动新 gTLD 计划提议相关的突出问题进行意见征询。双方都认同现在是进行此征询的合适时机。理事会将考虑 GAC 建议,审核为会议准备的所有文件(包括支持材料和参考)。此外,理事会在发布和修订每个申请人指南版本的整个流程中,针对 GAC 提出的问题咨询了所有利益主体。布鲁塞尔会议上将解决的 GAC 提出的具体问题在 GAC 卡塔赫纳公报中列出。 http://gac.icann.org/press-release/gac-2010-communique-39

      在理事会与 GAC 间召开布鲁塞尔会议并进行章程意见征询应该会对机构群体产生积极影响。这样可以向整个机构群体保证,理事会非常认真地对待意见征询流程及其章程要求,希望尽可能达成一致意见。

      布鲁塞尔会议的召开将对 ICANN 的财务预算产生很大影响,因为召开会议需要额外的差旅、住宿、会议空间资源和相关费用。这些费用包括某些 GAC 成员、理事会成员、工作人员及其他可能出席会议的代表的开销。未获得资金支持参与此次会议的 GAC 成员如果选择自己参加会议,也可能会感到一些财务影响。召开布鲁塞尔会议或进行章程意见征询不会导致与 DNS 相关的安全性、稳定性或灵活性问题。

    2. ICM

      在哥伦比亚卡塔赫纳会议期间,理事会表示同意工作人员的评估结论,即,如果理事会继续决定与 ICM Registry 就 .XXX sTLD 达成注册管理机构协议,可能会与 GAC 的建议发生冲突,因此启动了 GAC 意见征询流程。请参见 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#4

      在卡塔赫纳会议期间, GAC 寻求理事会对于其在 ICM 相关问题上立场的肯定与支持。

      为了使将来向 GAC 的意见征询尽可能有成效,理事会关于 GAC 建议所有事项的立场在随附的文档中明确声明。

      第 2011.01.25.28 号决议: 理事会指示工作人员向 GAC 提供声明了理事会关于 GAC 建议事项完全立场的文档。声明的理事会针对的是在其 2010 年 10 月 28 日会议上进行意见征询的事项。

      第 2011.01.25.29 号决议: ICANN 理事会特此决定,在卡塔赫纳启动的以及 ICANN 章程第 XI 条第 2 款第 1(j) 段中规定的关于 ICM 的意见征询不应晚于 2011 年 3 月 17 日星期四。

      2011.01.25.28 – 2011.01.25.29 号决议理由

      在理事会继续讨论 ICM 于 2010 年 10 月 28 日提出的关于 .XXX sTLD 的申请期间,确定了需要在理事会与 ICM 达成提议的注册管理机构协议之前向 GAC 征询的领域,因为某些 GAC 建议可能与理事会计划采取的举措不一致。理事会向 GAC 征询意见的义务是在 ICANN 章程第 XI 条第 2.1(j)-(k) 款中规定的,理事会在卡塔赫纳会议上正式启动了意见征询流程。为了使意见征询尽可能有成效,并且为了满足 GAC 的要求 - 获知理事会关于与 ICM 达成注册机构管理协议是否符合 GAC 建议的立场 - 附件中提供了更多的详细信息和具体引用材料,来支持理事会关于各项 GAC 建议的立场。

      提供全面的理事会立场文档通常会对公众产生积极的正面影响。随着围绕 .XXX sTLD 注册管理机构协议的预期批准展开的讨论继续进行,立场文档提供的详细信息和解释说明将使整个 ICANN 机构群体受益。此文档的提交不会对 ICANN 、机构群体或公众产生任何财务影响,不过,为方便理事会与 GAC 之间的讨论可能会发生额外成本和费用,包括差旅和住宿费用。立场文档的提供不会对 DNA 的安全性、稳定性或灵活性产生任何影响。

  5. 关于 AOC 审核的报告(包含 ATRT 建议)- 后续步骤

    《义务确认书》要求 ICANN 组织一次审核并于 2010 年 12 月 31 日之前完成,审核内容是检查其以下义务的执行情况:维护和改进关于公众意见、问责制和透明性的稳定机制,以确保其决策结果能够反映公众利益并对所有利益主体负责;

    根据确认书的要求,问责制和透明度审核小组 (ATRT) 于 2010 年 12 月 31 日提交了其最终报告,并发布了报告来征询公众意见;征询期截止到 2011 年 2 月 14 日;

    确认书声明,理事会将在收到报告后的六个月内实施达成的建议。

    第 2011.01.25.30 号决议: 理事会肯定了 ICANN ATRT 成员的努力工作和全心投入,并感谢这些志愿人员在期限紧张的情况下参与集中的公共流程,提出一套全面的 ICANN 改进建议。

    第 2011.01.25.31 号决议: 理事会呼吁公众对 ATRT 建议提出意见,并要求所有支持组织和咨询委员会以及提名委员会于 2011 年 2 月 14 日之前向理事会提供关于报告的初步意见,并请政府咨询委员会和提名委员会与理事会协作,讨论与其组织相关的建议的实施举措;

    第 2011.01.25.32 号决议: 理事会要求 ICANN 工作人员于 2011 年 2 月 21 日之前,参考收到的所有意见,向其提交一份关于理事会针对每项建议实施举措的提议,以及可行的针对建议的初步工作计划和预算提案,并提交一份关于所有建议的工作状态的报告。

    2011.01.25.30 – 2011.01.25.32 号决议理由

    要遵守《义务确认书》, ICANN 必须针对问责制和透明度小组 (ATRT) 最终报告中提出的每项建议的理事会实施举措提出提案。此项工作已经在进行当中, ICANN 对于问责制与透明度的承诺通过对该流程的透明跟进进一步实现。

    目前机构群体对 ATRT 最终建议的反馈仍在通过公开的公众意见征询流程收集。理事会实施举措提案的制定将对组织产生预算影响。为了制定该提案,需要专门分配大量人力资源,而提案本身也会提出关于建议实施的进一步预算考虑。有一种可能是,需要重新分配组织的财务资源,以允许足够的工作人员配备,来拟定有意义的提案。

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