Skip to main content
Resources

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

本页面还提供其他语种:

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

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

  1. 机密人事事宜 – 执行会议
  2. 认可议程
  3. BFC - 批准提高注册服务商委任申请费
  4. SIC - 批准理事会技术关系工作组章程
  5. 审查现有 gTLD 注册管理机构运营商的上下游融合
  6. ATRT
  7. IDN ccTLD 授权

 

  1. 机密人事事宜 – 执行会议

    在执行会议中 , 理事会通过了两项相关决议 ( 2011.04.21.C01 、 2011.04.21.C02 ), 根据《 ICANN 章程》第 III 条第 5.2 款 , 这两项协议仍将作为"与人事或雇用事宜相关的行动"予以保密。

  2. 认可议程

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

    2.1 批准 2011 年 3 月 18 日的 ICANN 理事会会议记录

    第 2011.04.21.01 号决议 : 理事会特此批准 2011 年 3 月 18 日的 ICANN 理事会会议记录。

    2.2 BGC – 举行组织会议以填补领导层空缺

    2011 年 6 月在新加坡举行的年中会议结束后 , 由于 ICANN 理事会第 11 位理事调任 , 届时理事会主席一职将产生空缺。

    理事会管理委员会已确定 , 由于理事会成员的调任 , 理事会倾向于立即填补 ICANN 理事会主席一职的空缺 , 以及立即对理事会委员会和领导层的人员构成做出任何必要的调整 , 同时 , 理事会管理委员会已准备就这些事宜向理事会提出建议。

    理事会组织会议需尽快在 2011 年 6 月的年中会议结束后举行 , 以便理事会选举主席 ( 以及副主席 , 如有必要 ) 以及按需要任命理事会委员会成员。

    第 2011.04.21.02 号决议 : 指示秘书长发出在 2011 年 6 月的年中会议结束后立即举行理事会组织会议的通知。

    第 2011.04.21.02 号决议的理由 :

    此行政决议确保理事会能够在理事会成员调任后继续拥有完整的领导层人员构成。由于组织会议在举行 2011 年年中会议的同一地点举行,因此此决定预期不会造成财政影响。此行动不会对域名系统的安全性、稳定性和灵活性造成影响。

    2.3 BGC – 经修订的行为准则

    理事会管理委员会 (BGC) 负责监督理事会是否遵守 2008 年批准的组织行为准则。

    BGC 已确定 , 行为准则指南会在遵守行为准则方面提供指导和协助。

    对行为准则做出的非实质性修订有必要纳入行为准则指南的参考信息部分 , 而且 BGC 已批准所提出的修订。

    第 2011.04.21.03 号决议 : 理事会批准经修订的行为准则 , 并指示工作人员将经修订的行为准则发布在 ICANN 网站上。

    第 2011.04.21.03 号决议的理由 :

    理事会遵守行为准则是保持 ICANN 决策流程的问责制和透明度的必要组成部分。 2008 年批准的行为准则是机构群体集思广益的结果,如今批准的改动实质上并未改变经机构群体审查的规定。经修订的行为准则中纳入的指南更加清晰地确定了用于处理潜在违反准则行为的流程,从而有助于理事会遵守行为准则。此决定预计不会造成财政影响,而且此行动也不会对域名系统的安全性、稳定性和灵活性造成影响。

    2.4 BGC – 有关 NomCom 学术界代表的意见

    《 ICANN 章程》 第 VII 条第 2.8.c 款 要求 NomCom 纳入一名由"理事会指定的代表学术组织和类似组织的实体 " ( 选定实体 ) 选出的有投票权成员。

    尽管理事会尝试确定选定实体,但没有成功,取而代之的是直接推荐代表作为 NomCom 的学术界代表。除了理事会选定的代表以外,每届 NomCom 一直都有多名来自学术界的代表。

    2010 年,理事会指示 BGC 制定流程,以确定选定实体,然而 BGC 对有关选定实体的确定和评估提出了疑虑。

    BGC 确定机构群体可以就适当的选定实体或有助于确定或评估选定实体的标准提供指导。

    如果机构群体的意见未能提供确定或批准适当选定实体的方案 , 则 BGC 准备建议将第 VII 条第 2.8.c 款从章程中删除。如果将来 NomCom 中的学术界代表人数不足 , 则应考虑制定机制 , 确保学术界在 ICANN 领导层的选拔中拥有发言权。

    第 2011.04.21.04 号决议: 理事会批准启动为期 30 天的公众意见征询,以收集机构群体意见,为 BGC 未来在实体确定方面的工作提供参考信息 , 以落实章程 第 VII 条第 2.8.c 款 中要求的 NomCom 任命工作 。 如果机构群体意见流程无法促成确定适当实体的方案,则公众意见也将提出有关删除此章程规定的潜在提议章程修正案。

    第 2011.04.21.04 号决议的理由 :

    目前的《 ICANN 章程》形式自 2002 年起采用 , 其中规定 NomCom 纳入一名由"理事会指定的代表学术组织和类似组织的实体" ( 选定实体 ) 任命的有投票权代表。理事会尚未成功确定这样一个选定实体;尽管 2003 年曾确定一个选定实体 ,但到 2005 年时,该实体还没有确定一名指定代表,理事会管理委员会 (BGC) 在征集提名后直接推荐了有投票权的 NomCom 代表。 2007 年,主席指出 BGC 没有成功确定选定实体 ; 2010 年, 理事会指示 ,通过 BGC 制定选定实体的选择流程并向理事会提出流程提案。

    尽管理事会在确定选定实体时面临限制 , 但除了 BGC 直接推荐的人员外 , 每届 NomCom 都有学术领域的代表。过去,除了指定的学术代表,近年来的每届 NomCom 都至少有两名与学术机构相关的成员。 NomCom 以及 NomCom 任职代表的选举方法对 ICANN 的领导和管理而言是十分重要的元素,让任何实体负责选举有投票权的 NomCom 代表都会对组织产生长远影响。 BGC 在着手制定用于确定选定实体的流程时,讨论了确定实体选择标准的困难性,特别是在有多个提议或提名的实体时,应该如何评估和选择一个成功的实体。 BGC 还发现一个更基本的问题:由于 NomCom 中一直存在提出学术性意见的人员,那么是否仍然有必要为 NomCom 确定一个特定的代表?

    BGC 建议机构群体在此决策点的审查中发表意见。 BGC 正在就以下问题寻求机构群体的指导 : 哪些实体可以或应该成为为 NomCom 指定学术成员的实体或类似组织?可以采用什么标准来评估参与竞争的实体?正确的选择和评估流程应该是怎样的?删除要求由此类实体选举代表的章程规定能否让机构群体得到更好的服务?

    需要说明的是,根据理事会指示, BGC 不需要为本届 (2010-2011) NomCom 确定一名行使该职责的代表。到目前为止, ICANN 尚未收到任何因为缺少特定学术代表而阻碍 NomCom 工作的投诉。

    如果征询机构群体的意见后仍然无法确定适当的选择、评估流程或实体,则 BGC 将建议删除章程中的这一规定。如果删除了这一规定,则必须审查 NomCom 将来的人员构成,以确保该构成中仍有学术界人员。如果将来学术界代表人数不足,将启动一项审查以研究如何以最好的方式保证 NomCom 的学术代表性。

    征求机构群体关于此事的意见有助于理事会评估任何 NomCom 人员构成的变化所带来的影响。此行动不会对域名系统的安全性、稳定性和灵活性造成影响。

    2.5 BGC – 批准理事会技术关系工作组成员

    2011 年 3 月 18 日 , 理事会成立理事会技术关系工作组 , "以考虑采取相关措施改善 ICANN 和其他互联网技术群体成员之间的协调合作 , 目的是在 2011 年年会前解散 TLG ; 理事会还要求该工作组邀请 ICANN 机构群体就 ICANN 和其他互联网技术群体成员之间的协调合作进行充分的民主协商。"

    本次会议上,理事会指示理事会管理委员会向理事会技术关系工作组推荐五位成员,供理事会考虑。

    在 2011 年 4 月 12 日的会议中 , BGC 审查了理事会技术关系工作组可能的人员构成 , 向理事会提供了一项建议 , 确定了以下工作组成员人选 :

    (i) Gonzalo Navarro , 主席 ;

    (ii) Thomas Narten ;

    (iii) Thomas Roessler ;

    (iv) Reinhard Scholl ; 及

    (v) Jonne Soininen 。

    第 2011.04.21.05 号决议 ,理事会批准了推荐的理事会技术关系工作组成员,并要求这些成员完成 2011 年 3 月 18 日 的理事会决议中所述的任务。

    第 2011.04.21.05 号决议的理由:

    为履行 2011 年 3 月 18 日的理事会决议 , 理事会管理委员会做出了推荐。 技术联络组 (TLG) 审查工作现在已成为机构群体意见征询的主题 , 预计工作组会在与 ICANN 机构群体一起进行的民主协商流程中执行其工作。

    工作组的人员构成预计会带来微小的财政影响 , 包括人力资源成本以及为促进工作组的工作而可能产生的费用。此行动不会对域名系统的安全性、稳定性和灵活性造成影响。

    2.6 SIC – 批准 ccNSO 审查实施举措

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

    负责为组织审查提供支持的 ICANN 工作人员和 ccNSO 在 " ccNSO 审查工作组最终报告 : 实施步骤"文件中 ( 2011 年 4 月发布 ) 提议了一套举措 , 以实施工作组提出的建议和结论并将其提交给 SIC 。

    SIC 认为包含在此文件中的措施恰当充分,并提议工作人员与 SIC 协作,根据此文件制定最终实施计划(包括估计成本),并将最终计划提交给理事会接收和考虑。

    第 2011.04.21.06 号决议 , 理事会批准 SIC 提出的文件 , 并指示 SIC 与工作人员协作 , 根据 SIC 建议的措施向理事会提交一份最终实施计划 ( 包括估计成本 ), 以实施 ccNSO 审查工作组最终报告中提出的结论和建议。

    第 2011.04.21.06 号决议的理由 :

    建议的举措直接回应了理事会的要求 , 有助于推进 ccNSO 审查结果的实施。制定详细的实施计划对于及时进行实施准备工作至关重要。由于该举措本身不会带来任何预算影响 , 因此没有任何理由推延此举措。详细的实施规划应该包含范围和资源估算 , 在完成详细的规划任务并提出详细计划后 ,这些因素 将由理事会考虑和决定。

    2.7 BFC – 成立现有员工退休储蓄账户 (401K) 计划委员会

    ICANN 退休储蓄计划 ( 简称"计划 " ) 于 2000 年推出 , 面向在美国的员工。

    由于计划参与者和资产数量的增加 , 根据最佳实践 , 应该成立一个计划委员会来实施计划管理 , 选择计划供应商 , 确定可供员工选择的投资方案以及其他受托责任。

    理事会财务委员会 (BFC) 已建议理事会批准成立 401(k) 计划委员会 , 并且授权首席执行官配置计划委员会的人员并监督其工作。

    第 2011.04.21.07 号决议 , 理事会批准成立 401(k) 计划委员会,并且授权首席执行官配置计划委员会的人员并监督其工作。

    第 2011.04.21.07 号决议的理由 :

    在美国的员工参与 ICANN 退休储蓄计划 ( 也称为 401(k) 计划 , 简称"计划 " ), 公司代表员工向"计划"缴款 , 员工也可以在延税基础上以自己的名义向"计划"缴款。 不久前,计划规模相对较小,不需要正式的计划委员会。但是最近 , "计划"发展到拥有 100 多个活跃参与者 , 且资产水平也大大提高 , 根据最佳实践 , 应该成立一个计划委员会来监督"计划"的方方面面。

    2.8 批准重新授权 .KP (朝鲜民主人民共和国)

    KP 是分配给朝鲜民主人民共和国的 ISO 3166-1 双字母国家代码。

    ICANN 收到一个请求 , 要求重新授权 .KP 给 Star Joint Venture 公司 ;

    ICANN 审查了该请求 , 并认为提议的重新授权符合当地及全球互联网群体的利益。

    第 2011.04.21.08 号决议 , 批准将 .KP 重新授权给 Star Joint Venture 公司的提议。

    第 2011.04.21.08 号决议的理由 :

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

    如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整,有获得理事会批准的前景时,会将其申请提交给理事会进行审批。根据 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 力求只批准此类请求:令人满意地解决了有理由担心的问题,并且提议的新管理者已充分展示出高水平的运营和技术能力,使这些问题最小化。

    2.9 批准跟进 IANA 关于 IPv4 耗尽后 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.04.21.09 号决议 : 理事会要求 ICANN 工作人员根据理事会关于此类政策提案的《审查程序》跟进题为 " IANA 关于 IPv4 耗尽后 IPv4 地址分配的全球政策"的政策提案的制定,并指示 ICANN 首席执行官为此目的指派工作人员。

    第 2011.04.21.09 号决议的理由:

    此《全球政策提案》已进入在所有地区互联网注册管理机构中展开讨论的阶段,并且适合启动制定和发布关于提案状态《背景报告》的工作。指导工作人员开展必要的跟进工作 , 是在 ICANN 与 ASO 的《谅解备忘录》中以及理事会 《全球互联网号码资源政策的审查程序》 中规定的 ICANN 衍生职责。

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

主要议程

  1. BFC – 批准提高注册服务商委任申请费

    潜在的利益冲突 ( 如总顾问所确定 ):

    Bruce Tonkin – 详情请参见公布的《利益声明概要》 – http://www.icann.org/en/board/summary-soi-16mar11-en.htm

    在第 01.65 号决议中,对于 2001 年 7 月 1 日及以后提交的委任申请,理事会批准收取 2500 美元的委任申请费,而不考虑所申请的委任负责的顶级域名数量。

    自 2001 年 7 月起,该申请费金额没有做出任何改变;

    2010 年 11 月 22 日 , ICANN 在其网站上公布了一项旨在完成其他的尽职调查和提高委任申请费的提案 , 提案对提议的尽职调查和提高申请费的理由做了说明。

    举行了在线公众意见征询,以便机构群体提交对提案的意见;

    收到的公众意见对提议的改进表示支持;

    第 2011.04.21.10 号决议 ,对于 2011 年 7 月 1 日及以后提交的委任申请,成为 ICANN 委任的注册服务商的申请费应为 3,500 美元。

    第 2011.04.21.11 号决议 , 理事会指示工作人员审核与注册服务商委任申请流程相关的成本 , 以确定当前的费用是否涵盖那些成本。

    第 2011.04.21.10-11 号决议的理由

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

    作为一种无需全面的政策制定或合同修正即可提高安全性的手段 , 这已成为机构群体讨论的主题。财务委员会已审查该决议,现在做出决定的时机已经成熟,可以在做出这一决定后才开始下一财年。

    讨论的提议是什么?

    理事会正在考虑是否批准将注册服务商委任申请费从 2,500 美元提高到 3,500 美元 , 这是 10 年来首次提高该费用。理事会也指示工作人员对与委任申请处理相关的成本进行全面的审核,以确保费用和成本一致。

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

    关于改进委任申请流程和提高费用的提案已在 2010 年 11 月 22 日至 2011 年 1 月 21 日征询公众意见 ; 我们收到四条意见 , 其中一条没有完全理解该提议 , 另外三条表示完全支持此提案。变更委任流程和申请费的提案在 ICANN 卡塔赫纳会议期间已递交给注册服务商利益主体组织,没有收到负面反馈。

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

    唯一的负面担心来自一位注册服务商,该注册服务商将申请费提高误解为注册服务商要缴纳的年费提高。没有提出其他关于申请费的担心。

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

    一份详细叙述提案的理事会文件以及一份附录,该附录描述了基于通过第三方进行背景调查的成本而提高申请费金额的理由。

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

    机构群体建议在注册服务商申请审查流程中改进尽职调查。理事会财务委员会审查并批准了提高申请费的财务理由 , 该费用提高不会影响收入。 BFC 进一步提出其他解决方案,认为应该对整个申请处理流程成本进行研究,以便确定如何使成本与费用相符。最终,公众意见论坛上没有提出反对意见。

    是否对机构群体有什么积极或消极的影响?

    提高此项费用使得改进尽职调查审查成为可能 , 从而加强审查流程 , 特别是在引入新 gTLD 后 , 注册服务商委任的利益预计会有所增加的情况下。

    是否会对 ICANN (战略规划、运营计划、预算)、群体和 / 或公众造成什么财政影响 / 后果?

    由于申请审查流程中将加入其他的背景调查 , 所以此项费用提高不会影响收入。

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

    引入提议的尽职调查是为了回应 ICANN 机构群体提出的安全隐忧,同时也是希望在不影响收入的情况下,借助此类尽职调查改进新注册服务商的委任流程。

  2. SIC – 批准理事会技术关系工作组章程

    2011 年 3 月 18 日 , 理事会决议接受 TLG 审查的最终报告 , 并成立一个理事会技术关系工作组 , 同时指示机构改进委员会 (SIC) "根据 TLG 审查报告、对该审查报告的意见以及任何其他可用信息制定该工作组章程 , 并在 2011 年 4 月 21 日的理事会会议上对此进行审议 " , 请参见 http://www.icann.org/zh/minutes/resolutions-18mar11-zh.htm#7

    SIC 已为理事会技术关系工作组 (BTR WG) 制定章程提案。

    SIC 于 2011 年 4 月 11 日的会议中一致同意建议理事会采用 BTR WG 章程提案。

    第 2011.04.21.12 号决议 : 理事会批准了 SIC 提议的 BTR WG 章程,该章程可能会在进行进一步审查后得到最终调整,同时理事会指示 SIC 与工作人员协调,以支持和跟进工作组的工作。

    第 2011.04.21.12 号决议的理由 :

    提议的举措直接回应了理事会的要求 , 有助于按照理事会设定的方向推进 TLG 审查结果的处理。由于起草这份章程没有征询机构群体的意见,亦无此必要,因此预计工作组会在建议实现后咨询机构群体。 BTR WG 的运作需要现有工作人员和一定限额资金的支持。由于该项举措只会带来非常小的预算影响,因此没有任何理由推延此举措。该项举措不会对 DNS 的安全性或稳定性造成任何影响。

  3. 审查现有 gTLD 注册管理机构运营商的上下游融合

    2010 年 11 月 5 日,理事会做出决议: ICANN 在新 gTLD 中将不会限制注册管理机构和注册服务商之间的交叉所有权, " ICANN 将允许现有的注册管理机构运营商转用新版注册管理机构协议,除非根据已建立注册管理机构的具体情况,有必要且适合使用附加条件。 "

    当前的 gTLD 注册管理机构协议包含交叉所有权限制。

    ICANN 已收到多个运营商的询问,他们想了解从注册管理机构协议中免除交叉所有权限制的流程和 / 或如何才能申请成为 ICANN 委任的注册服务商。

    免除运营商交叉所有权限制的前提是 : 一、理事会批准新 gTLD 计划 ; 二、理事会批准一项流程 , 使运营商可以转用新版注册管理机构协议或请求修订现有注册管理机构协议。

    理事会预计,它将会考虑新 gTLD 计划,并且会在 2011 年 6 月的新加坡会议上启动新 gTLD 。

    第 2011.04.21.13 号决议 ,理事会指示首席执行官制定一个流程,以便现有的 gTLD 注册管理机构运营商转用新版注册管理机构协议或请求修订注册管理机构协议以免除交叉所有权限制。这项流程将在理事会批准新 gTLD 计划后实施,适用于现有的运营商。

    第 2011.04.21.13 号决议的理由

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

    理事会现在要解决此问题是因为他们计划在 2011 年 6 月 20 日审议《新 gTLD 申请人指南》。 2010 年 11 月 4 日, ICANN 理事会做出决议,认为应该找出让现有 gTLD 注册管理机构运营商("运营商")转用新版注册管理机构协议的方法,包括免除注册管理机构和注册服务商之间的交叉所有权限制。运营商认为要及时免除当前关于交叉所有权的限制,以便在公平环境中与计划申请运营新 gTLD 的注册服务商竞争。批准一项流程,使现有运营商能够在理事会批准新 gTLD 计划的背景下及时免除交叉所有权限制,这种做法能表现出 ICANN 积极响应运营商请求的态度。

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

    运营商认为要及时免除他们当前关于交叉所有权的限制,以便与计划申请运营新 gTLD 的注册服务商竞争。当前没有任何限制妨碍注册服务商申请获得新 gTLD 注册管理机构运营商的运营权。

    是否对机构群体有什么积极或消极的影响?

    对机构群体有积极影响 , 因为现有的 gTLD 注册管理机构运营商将会被免除交叉所有权限制 , 这会使他们与新 gTLD 注册管理机构运营商处于同一公平竞争环境中。

    是否会对 ICANN ( 战略规划、运营计划、预算 ) 、群体和 / 或公众造成什么财政影响 / 后果 ?

    批准此决议对战略计划、运营计划和 / 或预算没有可预见的相关财政影响 / 后果。目前没有对机构群体或公众造成财政影响 / 后果的信息。

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

    目前尚未得知与 DNS 安全性、稳定性或灵活性相关的问题。

  4. ATRT

    6.1 理事会对 ATRT 建议的管理

    问责制和透明度审核小组 (ATRT) 报告提供了 27 条 ICANN 改进建议 , 义务确认书要求 ICANN 在 2011 年 6 月 30 日前对该报告采取措施 ;

    实施这些建议需要理事会做出大量工作 , 还要与重要的机构团体 ( 包括政府咨询委员会 ) 及工作人员展开广泛的协调合作 ;

    第 2011.04.21.14 号决议 , 理事会要求理事会的以下委员会在所附文件中 [PDF, 135 KB] 解决指定的 ATRT 建议。

    第 2011.04.21.14 号决议的理由 :

    按照义务确认书的要求,已向理事会提交了问责制和透明度审核小组 (ATRT) 的 建议,并予以公布以征询公众意见。 公众意见对 ATRT 报告表示认同,根据工作人员尽职调查的结果,建议 ICANN 推动 ATRT 建议的实施。工作人员提供了表明 ICANN 的建议实施能力的初步计划提案,并提供了估计的资源成本。 理事会要求工作人员与受影响的组织进行合作并制定最终实施计划提交理事会批准,同时理事会也表示 ICANN 已经在 ATRT 要求的多个运营变更的实施方面取得了进展。

    实施 ATRT 的 27 条建议需要理事会做出大量工作,还要与重要的机构团体(包括政府咨询委员会)及工作人员展开广泛的协调合作;为帮助确保迅速实施这些建议,理事会正在将建议的实施工作委托给相关的理事会委员会,并成立临时的理事会 -GAC 联合工作组以解决与 GAC 相关的建议。

    6.2 2012 财年中实施 ATRT 建议的估计预算

    理事会发现,问责制和透明度审核小组 (ATRT) 的 建议有可能推进 ICANN 的透明度和问责制目标,并可能在拥有必要支持和资源的情况下由 ICANN 在慎重明确的考虑后实施;

    2012 财年中估计需要 2,600,000 美元来完成 ATRT 实施活动;

    第 2011.04.21.15 号决议 ,理事会要求 BFC 考虑 2012 财年 ATRT 实施资金,工作人员应做出详细的财政预算并在下一次会议时向理事会汇报。

    第 2011.04.21.15 号决议的理由

    理事会先前指出 ATRT 的所有 27 条建议都可能推进 ICANN 的透明度和问责制目标,并可能在拥有必要支持和资源的情况下由 ICANN 在慎重明确的考虑后实施。理事会最近要求工作人员与受影响的组织进行合作并制定最终实施计划提交理事会批准,同时理事会也表示 ICANN 已经在 ATRT 要求的多个运营变更的实施方面取得了进展。理事会正在就建议的实施进行尽职调查,希望确保正在确定的 2012 财年预算包含相应的活动资金。

    理事会已批准在 2012 财年预算中包括实施 ATRT 建议的额外资金,并重申其推进 ICANN 问责制和透明度的承诺。

  5. IDN ccTLD 授权

    7.1 授权在阿拉伯语中代表阿尔及利亚的 الجزائر ("Al Jazair")

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

    编码为 "xn--lgbbat1ad8j" 的 الجزائر ("al-Jazair") 被视为是通过 IDN 快速通道流程表示阿尔及利亚的合适字符串 ;

    ICANN 收到了将 . الجزائر 授权给 Centre de Recherche sur l’Information Scientifique et Technique (CERIST) 的请求 ;

    ICANN 审查了此请求 , 并确定提议的授权符合地方和全球互联网群体的利益。

    第2011.04.21.16 号决议 ,批准将顶级域名 . الجزائر 授权给CERIST 的提案。

    第 2011.04.21.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 力求只批准此类请求 : 令人满意地解决了有理由担心的问题 , 并且提议的新管理者已充分展示出高水平的运营和技术能力 , 使这些问题最小化。

    7.2 授权在阿拉伯语中代表摩洛哥的 المغرب ("al-Maghrib")

    编码为 "xn--mgbc0a9azcg" 的 المغرب ("al-Maghrib") 被视为是通过 IDN 快速通道流程表示摩洛哥的合适字符串。

    ICANN 收到了将 .المغرب 授权给摩洛哥电信管理局 (Agence Nationale de Réglementation des Télécommunications) 的请求。

    ICANN 审查了此请求 , 并确定提议的授权符合地方和全球互联网群体的利益。

    第 2011.04.21.17 号决议 , 批准将域名 .المغرب 授权给摩洛哥电信管理局的提案。

    第 2011.04.21.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 力求只批准此类请求:令人满意地解决了有理由担心的问题,并且提议的新管理者已充分展示出高水平的运营和技术能力,使这些问题最小化。

    7.3 授权在西里尔语中代表塞尔维亚的域名 .срб ("srb")

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

    编码为 "xn--90a3ac" 的 срб ("srb") 被视为是通过 IDN 快速通道流程表示塞尔维亚的合适字符串 ;

    ICANN 收到了将 .срб 授权给塞尔维亚国家互联网域名注册处 ( Serbian National Register of Internet Domain Names , 简称 RNIDS ) 的请求 ;

    ICANN 审查了此请求 , 并确定提议的授权符合地方和全球互联网群体的利益。

    第 2011.04.21.18 号决议 : 批准将顶级域名 .срб 授权给塞尔维亚国家互联网域名注册处的提案。

    第 2011.04.21.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 力求只批准此类请求 : 令人满意地解决了有理由担心的问题 , 并且提议的新管理者已充分展示出高水平的运营和技术能力 , 使这些问题最小化。

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