Skip to main content
Resources

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

本页面还提供其他语种:

  1. 认可议程:
    1. 批准董事会会议记录
    2. 将代表前南斯拉夫马其顿共和国的 .MK 域名重新授权以及将代表前南斯拉夫马其顿共和国的 .мкд 域名授权给马其顿斯科普里学术研究网
    3. 将代表格鲁吉亚的格鲁吉亚文域名 გე("ge")授权给信息技术发展中心
    4. 延后 ccTLD .AN(荷属安的列斯)的移除日期
    5. 注册商利益相关方团体章程修订
    6. 感谢社群成员
    7. 感谢第 51 届 ICANN 会议的赞助商
    8. 感谢第 51 届 ICANN 会议的口译员、工作人员以及会议和酒店团队
  2. 主要议程:
    1. 感谢 2014 年度提名委员会
    2. 在新 gTLD 域名空间中引入双字符域名
    3. ICANN 2016-2020 财政年度战略规划
    4. 董事会对加强 ICANN 问责制跨社群工作组的建议的考虑
    5. 感谢奥尔加·马德鲁加-福蒂女士 (Olga Madruga-Forti) 为 ICANN 董事会做出的贡献
    6. 感谢塞巴斯蒂安·巴肖莱 (Sébastien Bachollet) 为 ICANN 董事会做出的贡献
    7. 感谢比尔·格雷厄姆 (Bill Graham) 为 ICANN 董事会做出的贡献
    8. 感谢希瑟·德莱顿为 ICANN 董事会做出的贡献

 

  1. 认可议程:

    1. 批准董事会会议记录

      第 2014.10.16.01 号决议:董事会批准 2014 年 9 月 9 日 ICANN 董事会例行会议的会议记录。

    2. 将代表前南斯拉夫马其顿共和国的 .MK 域名重新授权以及将代表前南斯拉夫马其顿共和国的 .мкд 域名授权给马其顿斯科普里学术研究网

      第 2014.10.16.02 号决议:根据 IANA 职能合同中所述的职责,ICANN 已审核并评估将国家和地区代码顶级域名 .MK 重新授权以及将国家和地区代码顶级域名 .мкд IDN 授权给马其顿斯科普里学术研究网 (Macedonian Academic Research Network Skopje) 的申请。文件材料显示,在评估此申请时,工作人员严格遵守了相应流程。

      第 2014.10.16.03 号决议:董事会指示,根据《ICANN 章程》第 III 条第 5.2 款,为了履行合同义务,决议、初步报告或会议记录中的部分理由目前不宜公之于众,应等待适当时机再予以公布。

      第 2014.10.16.02 – 2014.10.16.03 号决议的理由

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

      根据 IANA 职能合同的要求,ICANN 工作人员已评估请求重新授权和授权 ccTLD 的两份申请,且目前正将评估报告提请董事会审核。提请董事会审核的目的是确保 ICANN 工作人员严格遵守了相应流程。

      正在考虑的提案是什么?

      正在考虑的提案是,批准 IANA 部门收到的、请求将国家和地区代码顶级域名 .мкд 及 .MK 的注册提供方(也称为管理机构或受托机构)指定和变更为马其顿斯科普里学术研究网的两份申请。

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

      在评估授权申请和重新授权申请的过程中,ICANN 工作人员咨询了申请人和其他利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述该 ccTLD 对其本地互联网社群的适用性。

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

      工作人员未发现社群成员就此申请提出任何重大问题或顾虑。

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

      董事会审核了 IANA 部门工作人员的以下评估结果:

      • MK 是 ISO 3166-1 标准中为前南斯拉夫马其顿共和国指定的 alpha-2 代码,мкд 是经批准的代表前南斯拉夫马其顿共和国的国际化域名字符串,这两个域名均符合继续授权的资格;
      • 申请得到了现有注册提供方外交部的同意;
      • 已咨询过相关政府且后者并不反对;
      • 拟议提供方及其联系人同意承担管理这些域名的职责;
      • 提案已经适当地征询了本地互联网社群的意见并得到其支持;
      • 提案与任何已知法律或法规不抵触;
      • 提案保证这些域名将在该国本地管理,并受当地法律约束;
      • 拟议提供方已确认,他们将以公平、公正的方式管理这些域名;
      • 拟议提供方已展示了用于运营这些域名的适当运营和技术技能、计划;
      • 拟议技术配置符合 IANA 部门的各种技术合规要求;
      • 未发现关于互联网稳定性的具体风险或顾虑;以及
      • 工作人员已建议根据考虑的各方面因素实施这两份申请。

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

      作为 IANA 职能合同规定流程的一部分,"授权和重新授权报告"将发布到 http://www.iana.org/reports

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

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

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

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

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

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

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

      ICANN 认为这两份申请不会给安全性、稳定性或灵活性带来任何明显风险。

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

    3. 将代表格鲁吉亚的格鲁吉亚文域名 გე("ge")授权给信息技术发展中心

      第 2014.10.16.04 号决议:根据 IANA 职能合同中所述的职责,ICANN 已审核并评估将国家和地区代码顶级域名 გე 授权给信息技术发展中心 (ITDC) 的申请。文件材料显示,在评估此申请时,工作人员严格遵守了相应流程。

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

      第 2014.10.16.04 – 2014.10.16.05 号决议的理由

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

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

      正在考虑的提案是什么?

      正在考虑的提案是,批准 IANA 收到的、请求创建国家和地区代码顶级域名并将该域名的注册提供方(也称为管理机构或受托机构)指定为信息技术发展中心 (ITDC) 的申请。

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

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

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

      工作人员未发现社群成员就此申请提出任何重大问题或顾虑。

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

      董事会审核了 IANA 部门工作人员的以下评估结果:

      • 该域名是经 IDN ccTLD 快速通道流程批准的字符串,且代表 ISO 3166-1 标准中列出的国家或地区,因此具备授权资格;
      • 已咨询过相关政府且后者并不反对;
      • 拟议提供方及其联系人同意承担管理该域名的职责;
      • 提案已经适当地征询了本地互联网社群的意见并得到其支持;
      • 提案与任何已知法律或法规不抵触;
      • 提案保证该域名将在该国本地管理,并受当地法律约束;
      • 拟议提供方已确认,他们将以公平、公正的方式管理该域名;
      • 拟议提供方已展示了用于运营该域名的适当运营和技术技能、计划;
      • 拟议技术配置符合 IANA 部门的各种技术合规要求;
      • 未发现关于互联网稳定性的具体风险或顾虑;以及
      • 工作人员已建议根据考虑的各方面因素实施该申请。

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

      作为 IANA 职能合同规定流程的一部分,"授权和重新授权报告"将发布到 http://www.iana.org/reports

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

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

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

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

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

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

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

      ICANN 认为此申请不会给安全性、稳定性或灵活性带来明显风险。

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

    4. 延后 ccTLD .AN(荷属安的列斯)的移除日期

      鉴于顶级域名 .AN 在其 ISO 3166-1 国家和地区代码被新代码取代后迎来了退役。

      鉴于董事会在 2011 年 10 月 11 日的决议中表示 .AN 域名的使用期限应截止为 2014 年 10 月 31 日。

      鉴于 .AN 域名的运营商和荷兰经济部部长申请将该截止期限延长 9 个月,以便为剩余的注册人提供额外的机会,让他们能完成从 .AN 域名的迁出。

      兹此发布第 2014.10.16.06 号决议:将 .AN 域名从 RDS 根域中移除的截止时间延后至 2015 年 7 月 31 日。

      第 2014.10.16.06 号决议的理由

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

      根据之前的决议,应在 2014 年 10 月 31 日之前将顶级域名 .AN 从 DNS 根域中移除。.AN 运营商和荷兰经济部部长已经要求延后移除日期。

      正在考虑的提案是什么?

      该申请旨在将顶级域名 .AN 的退役日期延后至 2015 年 7 月 31 日。

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

      .AN 运营商表示,尽管大部分域名注册人已经迁移到新的域名,但仍有约 30 位的少数注册人需要更多时间才能完成迁移。运营商担心剩余的注册人无法在当前的截止期限内完成迁移。

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

      批准所申请的延期将允许 ICANN 工作人员和当前运营商一起结束 .AN 域名的使用。这体现了 IANA 职能部门在履行自己义务时以及在与社群协作、考虑社群需求时的尽职尽责。

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

      管理 DNS 根域中的国家和地区代码授权是 IANA 职责的一部分,延后 .AN 的退役日期不会对预先计划的开支有任何重大影响。评估国家和地区代码顶级域名在特定国家或地区内部所产生的财政影响并不是 ICANN 的职责。

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

      批准所申请的延期有助于在 ICANN 与运营商试图将 .AN 域名从 DNS 根域中移除时,维持 .AN 域名的安全性和稳定性。

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

    5. 注册商利益相关方团体章程修订

      鉴于 GNSO 注册商利益相关方团体 (RrSG) 针对其制度性章程文件提出了一系列修订。

      鉴于 RrSG、ICANN 工作人员和结构改进委员会 (SIC) 完成了董事会 GNSO 利益相关方团体和选区章程修订流程规定的所有要求。

      兹此发布第 2014.10.16.07 号决议:ICANN 董事会批准注册商利益相关方团体章程修订,并指示工作人员在适当网页上提供该团体这一新制度性文件的访问路径。

      第 2014.10.16.07 号决议的理由

      《ICANN 章程》(第 X 条第 5.3 款)规定"每个利益相关方团体都应确保获得 ICANN 董事会的认可。"董事会对这一规定的解释为,通用名称支持组织 (GNSO) 内的利益相关方团体 (SG) 和/或选区如对自己的制度性文件有任何修改,必须获得 ICANN 董事会的正式批准。

      2013 年 9 月,董事会制定了 GNSO 利益相关方团体和选区章程修订流程(流程),旨在为遵守《ICANN 章程》规定提供一种简化的方法。

      GNSO 注册商利益相关方团体 (RrSG)、ICANN 工作人员和结构改进委员会 (SIC) 完成了流程中要求的所有步骤,包括确定拟议的章程修订不会给 ICANN 组织带来任何财务或责任问题以及公布修订内容供社群了解和征询社群意见(未收到反对意见)。

      此项决定不会对域名系统的安全性、稳定性和灵活性造成任何预期影响。

    6. 感谢社群成员

      鉴于 ICANN 希望感谢各利益相关方社群成员为 ICANN 流程贡献的大量精力和技能。

      鉴于当社群成员在支持组织和咨询委员会内部的任期结束时,ICANN 希望对他们表示感谢,以认可他们所做出的贡献。

      鉴于以下一般会员社群成员即将离任:

      • 纳利亚·阿卜杜尔·拉罕姆 (Rinalia Abdul Rahim) - 一般会员社群 IDN 工作组联合主席
      • 福阿德·巴杰瓦 (Fouad Bajwa) - APRALO 副主席
      • 奥利维尔·科雷鹏-勒布朗 (Olivier Crépin-Leblond) - ALAC 主席
      • 艾伦·格林伯格 (Alan Greenberg) - ALAC 的 GNSO 联络人
      • 菲利普·约翰逊 (Philip Johnson) - AFRALO 秘书
      • 埃文·雷波维奇 (Evan Leibovitch) - ALAC 副主席 (NARALO)
      • 格伦·麦克奈特 (Glenn McKnight) - NARALO 秘书
      • 让-雅克·苏布伦内 (Jean-Jacques Subrenat) - ALAC 成员(EURALO,提名委员会代表)
      • 戴夫·阿诺德·蒂拉克辛 (Dev Anand Teelucksingh) - ALAC 成员 (LACRALO)

      兹此发布第 2014.10.16.08 号决议:董事会对纳利亚·阿卜杜尔·拉罕姆、福阿德·巴杰瓦、奥利维尔·科雷鹏-勒布朗、艾伦·格林伯格、菲利普·约翰逊、埃文·雷波维奇、格伦·麦克奈特、让-雅克·苏布伦内和戴夫·阿诺德·蒂拉克辛在其各自任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于以下地址支持组织 (ASO) 地址理事会成员 (AC) 即将离任:

      • 纳雷什·阿贾尼 (Naresh Ajawani) – ASO AC 成员

      兹此发布第 2014.10.16.09 号决议:董事会对纳雷什·阿贾尼在任期内所做的工作深表感谢,并祝愿他未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于以下国家和地区代码名称支持组织 (ccNSO) 理事会的成员即将离任:

      • 基思·戴维森 (Keith Davidson) – 解释框架工作组主席
      • 薛红 – ccNSO 理事

      兹此发布第 2014.10.16.10 号决议:董事会对基思·戴维森和薛红在其各自任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于以下通用名称支持组织 (GNSO) 成员即将离任:

      • 约翰·伯纳德 (John Berard) – GNSO 理事(企业和商业用户选区)
      • 乔敬 (Ching Chiao) – GNSO 理事(注册局利益相关方团体)
      • 杰弗里·艾克霍斯 (Jeffrey Eckhaus) – 注册商利益相关方团体副主席
      • 玛丽亚·法瑞尔 (Maria Farrell) – GNSO 理事(非商业用户选区)
      • 玛佳丽·帕泽洛 (Magaly Pazello) – GNSO 理事(非商业用户选区)
      • 培特·林德福特 (Petter Rindforth) – GNSO 理事(知识产权利益选区)
      • 克劳斯·斯托尔 (Klaus Stoll) – GNSO 理事(非营利运营关切选区)
      • 珍妮弗·沃尔夫 (Jennifer Wolfe) – GNSO 理事(提名委员会代表)

      兹此发布第 2014.10.16.11 号决议:董事会对约翰·伯纳德、乔敬、杰弗里·艾克霍斯、玛丽亚·法瑞尔、玛佳丽·帕泽洛、培特·林德福特、克劳斯·斯托尔和珍妮弗·沃尔夫在其各自任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

      鉴于以下提名委员会 (NomCom) 成员即将离任:

      • 罗恩·安德鲁夫 (Ron Andruff) – 企业和商业用户选区代表
      • 维若妮卡·克雷楚 (Veronica Cretu) – 一般会员咨询委员会代表
      • 威廉·曼宁 (William Manning) – RSSAC 代表
      • 约翰·麦克尔韦恩 (John McElwaine) – 知识产权选区代表
      • 拉斯·芒迪 (Russ Mundy) – IAB 在 IETF 中的代表
      • 凡达·斯卡特兹尼 (Vanda Scartezini) – 一般会员咨询委员会代表

      兹此发布第 2014.10.16.12 号决议:董事会对罗恩·安德鲁夫、维若妮卡·克雷楚、威廉·曼宁、约翰·麦克尔韦恩、拉斯·芒迪和凡达·斯卡特兹尼在其各自任期内所做的工作深表感谢,并祝愿他们未来在 ICANN 社群内外的工作和生活一切顺利。

    7. 感谢第 51 届 ICANN 会议的赞助商

      董事会希望对以下赞助商表示感谢:Verisign, Inc.、公共利益注册局、Afilias Limited、PDR Solutions FZC、Community.Asia、Neustar、Freenom、中国互联网络信息中心、.GLOBAL、.CLUB Domains、CentralNic、Brandma.Co、NCC Group、商标信息交换中心、环球互易资讯(控股)集团香港有限公司、Uniregistry Corp.、ZA Central Registry、Minds + Machines Group、Iron Mountain, Inc.、INOC、Radix FZC 和 ICANNWIKI。

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

      董事会对书记员、口译员、视听团队、技术团队和全体 ICANN 工作人员为会议顺利进行所付出的努力表示最深的谢意。

      董事会还要感谢凯悦世纪广场酒店 (Grand Hyatt Century Plaza Hotel) 的管理层和工作人员为召开本次会议提供了优良的场所和设施。特别感谢活动策划副总监金姆·阿拉贡 (Kim Aragon) 和国际销售经理苏茜·舒尔茨 (Susie Schultz)。

  2. 主要议程:

    1. 感谢 2014 年度提名委员会

      鉴于 ICANN 已任命谢丽尔·兰登-奥尔 (Cheryl Langdon-Orr) 为 2014 年度提名委员会的主席,斯特凡·范·盖尔德 (Stéphane Van Gelder) 为 2014 年度提名委员会的候任主席以及约里奥·兰斯普罗 (Yrjö Länsipuro) 为副主席。

      鉴于 2014 年度提名委员会由各 ICANN 社群和咨询机构的代表组成。

      兹此发布第 2014.10.16.13 号决议:ICANN 董事会对谢丽尔·兰登-奥尔、斯特凡·范·盖尔德、约里奥·兰斯普罗以及 2014 年度提名委员会所有成员(包括罗恩·安德鲁夫、萨蒂什·巴布 [Satish Babu]、约翰·伯利赫 [John Berryhill]、阿兰·比德罗恩 [Alain Bidron]、唐·布卢门撒尔 [Don Blumenthal]、维若妮卡·克雷楚、萨拉·多伊奇 [Sarah B. Deutsch]、罗伯特·格拉 [Robert Guerra]、汉斯·皮特·霍伦 [Hans Petter Holen]、路易·霍尔 [Louis Houle]、尤哈尼·尤塞柳斯 [Juhani Juselius]、布伦登·屈比斯 [Brenden Kuerbis]、比尔·曼宁 [Bill Manning]、约翰·麦克尔韦恩、拉斯·芒迪、凡达·斯卡特兹尼和法迪玛他·塞耶·西拉 [Fatimata Seye Sylla])的奉献精神、勤奋工作和努力深表感谢。

    2. 在新 gTLD 域名空间中引入双字符域名

      鉴于 ICANN 注册局服务技术评估小组 (RSTEP) 在 2006 年 12 月 4 日确定,拟议的在 .name gTLD 中释放双字符二级域名 (SLD) 不会对安全性和稳定性带来严重不利影响风险。

      鉴于根据《新 gTLD 注册局协议》规定 5 第 2 条的要求,双字符标签"应保留注册或保留分配给二级域名的注册局运营商。此类标签不得在 DNS 中激活,也不得释放,以防除注册局运营商之外的任何个人或实体进行注册,但是,如果注册局运营商与 ISO 3166-1 alpha-2 标准中指定的相关政府和国家/地区代码字符串管理者达成协议,则可释放此类双字符标签字符串。注册局运营商在为避免相应国家/地区代码出现混淆而要采取相应措施的情况下,也可以提议释放这些保留字符标签,但须获得 ICANN 的批准"。

      鉴于自 2014 年 1 月 18 日以来,代表 207 个新 gTLD 的注册局运营商已经提交了多份注册局服务评估政策 (RSEP) 申请,希望在释放各个双字符标签集时实施新的注册局服务。

      鉴于 ICANN 就每份 RSEP 申请都做了初步决定,认为申请中提出的这些注册局服务不会加重"安全性"、"稳定性"和"竞争"问题(参见 RSEP 中这些术语的定义)。

      鉴于政府咨询委员会 (GAC) 表示部分 GAC 成员对释放字母/字母组合的双字符域名存有顾虑,故 GAC 打算在 ICANN 第 51 届洛杉矶会议期间对这一议题展开讨论。

      鉴于 GAC 在其洛杉矶公报 [PDF, 127 KB] (2014 年 10 月 15 日)中指出,GAC"未就在新 gTLD 运营中使用双字符二级域名(包括 ISO 3166-1 alpha 2 列表中列出的那些字母组合)的问题达成共识性建议。"GAC 还指出,"在考虑这些 RSEP 申请时,根据《申请人指导手册》,GAC 认为公共意见征询是一项非常重要的透明机制,而且,GAC 还认为 ICANN 在收到这类申请时应告知有关政府。"

      兹此发布第 2014.10.16.14 号决议:鉴于为了在 gTLD 域名空间中释放双字符域名而提出的注册局服务不会给安全性和稳定性带来严重不利影响风险,董事会授权总裁兼首席执行官(或其指定人员)在考虑 GAC 洛杉矶公报建议的前提下,制定并实施有效的程序,以释放目前《新 gTLD 注册局协议》要求予以保留的双字符域名。

      第 2014.10.16.14 号决议的理由

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

      《新 gTLD 注册局协议》规定 5(保留名称一览表)第 2 条对双字符标签的保留问题做了规定,原文如下:

      所有双字符 ASCII 标签应保留注册或保留分配给 TLD 中二级域名的注册局运营商。此类标签不得在 DNS 中激活,也不得释放,以防除注册局运营商之外的任何个人或实体进行注册,但是,如果注册局运营商与 ISO 3166-1 alpha-2 标准中指定的相关政府和国家/地区代码字符串管理者达成协议,则可释放此类双字符标签字符串。注册局运营商在为避免相应国家/地区代码出现混淆而要采取相应措施的情况下,也可以提议释放这些保留字符标签,但须获得 ICANN 的批准。

      2014 年 1 月,新 gTLD 注册局运营商开始通过注册局服务评估政策 (RSEP) 流程向 ICANN 提交申请,建议通过实施新的注册局服务来释放《新 gTLD 注册局协议》规定必须保留的某些双字符域名。如果要实施这些提议,则需要对各自注册局协议附录 A 的内容进行修订。在过去几个月里,ICANN 曾就旨在实施新注册局服务的拟议修订案多次启动公共评议期。到目前为止,ICANN 共发布了 28 份 RSEP 提案,涉及 203 个新 gTLD。如今,ICANN 仍会每周收到关于相同注册局服务的更多 RSEP 申请。

      根据 RSEP 第 2.4.D 款和"RSEP 实施注意事项",如果实施拟议的服务需要对注册局协议作出重大更改,则 ICANN 应将初步决定提交 ICANN 董事会审议。

      正在考虑的提案是什么?

      此时此刻,董事会采取的行动是,指示总裁兼首席执行官在考虑 GAC 洛杉矶公报建议的前提下,制定并实施有效的程序,以实现向新 gTLD 域名空间内释放双字符域名。

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

      截至 2014 年 9 月 24 日,ICANN 工作人员共启动了五 (5) 次公众意见论坛,旨在收集社群关于修订注册局协议以实施拟议的新注册局服务的反馈意见:2014 年 6 月 12 日 <https://www.icann.org/public-comments/two-char-new-gtld-2014-06-12-en>;2014 年 7 月 8 日 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-08-en>;2014 年 7 月 23 日 <https://www.icann.org/public-comments/two-char-new-gtld-2014-07-23-en>;2014 年 8 月 19 日 <https://www.icann.org/public-comments/two-char-new-gtld-2014-08-19-en> 以及 2014 年 9 月 12 日 <https://www.icann.org/public-comments/two-char-new-gtld-2014-09-12-en>。许多社群成员均提交了意见,包括一般会员咨询委员会 (ALAC) 和注册局运营商。

      此外,ICANN 还通知了 GAC 何时公布注册局运营商提交的申请以征询公众意见。

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

      公共评议期间共收到了多份意见,有支持在新 gTLD 域名空间内释放部分双字符域名的,也有反对释放的。其中,大部分意见均对释放双字符域名表示支持。

      那些反对释放的意见主要提出了两点担忧。第一是有关普遍认可的问题以及双字符域名的使用可能会导致用户混淆或滥用。第二个担忧是,如果要重新确立国家和地区名称,如何才能确保 ccTLD 得到保护。

      在目前为止收到的公众意见中,支持向新 gTLD 域名空间引入双字符域名的意见占据绝对优势。支持者们给出的理由如下:

      • 引入双字符域名可促进竞争,当前的限制阻碍了竞争,尤其是对新 gTLD 而言,因为新 gTLD 要与旧 TLD(2012 年新 gTLD 申请轮次之前授权的 TLD)竞争,而后者允许提供此类双字符域名注册。当前对新 gTLD 注册局运营商的限制实属差别对待,这与《ICANN 章程》第 II 条第 3 款要求给予 ICANN 利益相关方无差别对待的规定不符。
      • 根据之前在现有 TLD 中使用双字符域名的经验来看,引入双字符域名可造成的混淆风险非常有限,或者完全不会造成混淆风险。
      • 释放某些至少包含一位数字的双字符域名类型不会造成任何问题,可考虑释放。
      • 释放双字符域名将允许公司和品牌通过定制细分域名来与公众沟通和提供本地化内容,从而可扩大消费者选择,推动经济增长,尤其是对发展中国家而言。
      • 拟议的注册局服务与权利保护机制 (RPM) 要求文档的内容并不冲突。
      • 在以往相关的 RSEP 申请中也有关于释放双字符域名的统一先例。
      • 释放国家和地区代码及名称是《申请人指导手册》允许的行为。

      GAC 也就释放某些双字符域名提出了自己的一些顾虑(即字母/字母组合)。在于 2014 年 3 月 27 日发布的新加坡公报中,GAC 曾探讨过品牌注册局团体的提案,该团体在提案中建议在注册局协议附录下新增一项批准二级国家/地区名称及双字母和字符代码的流程。GAC 表示,"尽管 GAC 对品牌所有者寻求此类名称的批准没有重大顾虑,但这类批准应直接与相关国家/地区交涉完成,而不是通过 GAC 级别的操作流程执行。"GAC 在公报中指出,GAC 成员可根据需要帮助解决有关自己国家/地区的提案。GAC 建议,应考虑建立不需要提交单个申请的国家/地区注册。

      之后,GAC 又在其洛杉矶公报中指出,GAC"未就在新 gTLD 运营中使用双字符二级域名(包括 ISO 3166-1 alpha 2 列表中列出的那些字母组合)的问题达成共识性建议。"GAC 还指出,"在考虑这些 RSEP 申请时,根据《申请人指导手册》,GAC 认为公共意见征询是一项非常重要的透明机制,而且,GAC 还认为 ICANN 在收到这类申请时应告知有关政府。"董事会现阶段的行动考虑了 GAC 关于释放双字符域名的意见。

      董事会审核了哪些重要材料?董事会认为至关重要的因素有哪些?

      在审议是否批准该申请时,董事会审核了若干材料,也考虑了许多重要因素。董事会在审议中考量的重要材料和因素包括但不限于如下各项:

      是否会对社群产生积极或者消极影响?是否会在财务方面对 ICANN(战略规划、运营规划、预算)、社群和/或公众产生影响或不良后果?是否存在与 DNS 相关的任何安全性、稳定性或灵活性问题?

      鉴于引入双字符域名将为 gTLD 域名空间创造新的多样化和竞争机会,因此这一决定对社群的总体影响应该是积极的,而且目前尚未发现任何用户混淆风险。

      此注册局服务的最终实施可能对 ICANN、社群或公众产生财务影响,因为此注册局服务的更广泛应用可能涉及其他费用。

      正如 ICANN 注册局服务技术评估专家组在关于在 .name gTLD 内释放双字符域名的 2006 年 12 月 4 日报告中所说的那样,此类服务不会给安全性和稳定性带来严重不利影响风险。

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

      注册局服务评估政策是一项 ICANN 共识性政策,自 2006 年 8 月 15 日起生效。由于实施拟议的服务需要对注册局协议作出在当时认为是很重大的更改,因此 ICANN 依据该政策公布了注册局协议修订案以征询公众意见。在今天发布这项决议之后,将来请求释放由双字符域名组成的字母/数字或数字/数字组合名称的 RSEP 将无需再对注册局协议作出重大更改。

    3. ICANN 2016-2020 财政年度战略规划

      鉴于 ICANN 2016-2020 财政年度战略规划始于 2013 年 4 月,是多利益相关方在网上以及在 ICANN 北京会议期间开展的范围广泛、协作式、自下而上、多语言的流程的结果(详细信息请参见在线资源))。

      鉴于战略规划提出了新的 ICANN 愿景、重申了 ICANN 当前的使命并阐述了五大战略目标,每个战略目标又包括阶段性战略目标、关键成功因素以及战略风险。

      鉴于作为战略规划的补充,五年运营规划对每个战略目标和阶段性目标做了详细计划,包括 ICANN 活动、关键运营成功因素、运营风险、关键绩效指标、关键依赖关系以及五年内的阶段划分(阶段性目标级别),这些详细计划将为年度运营规划和预算提供依据。

      兹此发布第 2014.10.16.15 号决议:ICANN 2016-2020 财政年度战略规划获得通过,ICANN 总裁兼首席执行官需采取必要的行动来发布和执行规划。

      第 2014.10.16.15 号决议的理由

      战略规划提出了 ICANN 愿景、重申了 ICANN 使命并设定了五大战略目标,每个战略目标又包括阶段性战略目标、关键成功因素(成果)以及战略风险。它将引导 ICANN 在 2016-2020 财政年度期间的活动,并为 ICANN 的运营规划和预算提供指导信息。

      为了让公众能更深入地了解该规划,同时为了加强 ICANN 的问责制和透明度,五年运营规划作为战略规划的补充,在后者的基础上详细阐述了相关衡量指标(关键绩效指标)以及高水平的五年阶段划分。作为 ICANN 规划流程中的一个新元素,五年运营规划对每个战略目标和阶段性目标做了详细计划,包括 ICANN 活动、关键运营成功因素(成果)、风险、关键绩效指标(衡量指标)、关键依赖关系以及五年内的阶段划分(阶段性目标级别)。

      从 2016 财年开始,战略规划将与五年运营规划一起,为 ICANN 的年度运营规划和预算提供指导信息。这些年度运营规划和预算旨在解决各项战略的资源要求以及其对 DNS 安全性、稳定性和灵活性的影响,并提出任何必要的风险缓解措施。

      在实现战略目标和有效性过程中取得的工作进展和成就将通过 ICANN 管理系统进行管理和报告,包括一系列关键成功因素和关键绩效指标。这些数据将为年度规划稽核提供依据,从而确定组织是否处于正轨,还是需要适当做出调整。

      ICANN 战略规划始于 2013 年 4 月,是多利益相关方在网上以及在 ICANN 北京会议期间开展的范围广泛、协作式、自下而上、多语言的流程的结果。ICANN 已就其中的关键挑战与机遇以及 ICANN 董事会强调的战略领域广泛征询了公众意见。这些涉及 ICANN 支持组织、利益相关方团体、选区和咨询委员会的公众意见及社群讨论(详细信息请单击此处)了解)为战略规划的各个方面均提供了参考。对有关战略规划草案的所有公众意见的回复可单击此处 [PDF, 808 KB] 和此处 [PDF, 414 KB]了解。此战略规划还参考了诸如安全性、稳定性和灵活性框架、区域合作战略和战略专家组战略主题等相关举措的工作和意见。

    4. 董事会对加强 ICANN 问责制跨社群工作组的建议的考虑

      鉴于董事会承认社群在召集负责加强 ICANN 问责制的跨社群工作组方面行动迅速。

      鉴于一直以来,社群针对加强 ICNAN 问责制流程提出的意见都非常宝贵,董事会期待收到拥有广泛社群支持并在广泛社群内达成共识的建议。

      鉴于董事会明白,有关董事会将如何处理加强 ICANN 问责制跨社群工作组提出的共识性建议的问题仍未解决。

      兹此发布第 2014.10.16.17 号决议:董事会承诺在考虑加强 ICANN 问责制和治理跨社群工作组提出的建议时遵循以下原则:

      1. 这些原则适用于加强 ICANN 问责制和治理跨社群工作组提出的共识性建议。
      2. 如果董事会认为实施加强 ICANN 问责制和治理跨社群工作组提出的建议(CCWG 建议)不符合全球公共利益,董事会必须启动与 CCWG 的对话。确定实施 CCWG 建议不符合全球公共利益的决定必须获得董事会 2/3 多数成员的投票。
      3. 董事会必须在启动对话时提供详细的理由。关于开展对话的方式(如电话会议、电子邮件或其他),董事会应与 CCWG 达成一致意见。双方应本着真诚合作的态度,通过及时高效的方式进行讨论,力求找到一个彼此都能够接受的解决方案。
      4. CCWG 将有一次解决董事会顾虑并向董事会提交有关董事会顾虑的进一步审议报告的机会。CCWG 应在董事会启动对话后 30 天内完成关于董事会顾虑的讨论。
      5. 如果 CCWG 对建议进行了修改,可再次提交给董事会供其进一步审议。CCWG 需详细地说明该修改将如何解决董事会提出的顾虑。
      6. 如果在修改建议后,董事会仍然认为实施 CCWG 建议不符合全球公共利益,则董事会可以将具体建议项发送给 CCWG 进一步考虑,同样,采取这一行动需要董事会 2/3 多数成员的投票。董事会需详细说明这一行动的理由。如果董事会决定不接受修改,则在 CCWG 和董事会双方达成共识之前,董事会将无权针对建议所涉及问题制定解决方案。

      第 2014.10.16.16 号决议的理由

      在 ICANN 与美国政府之间的历史合作关系发生改变后,社群提出了对 ICANN 问责制进行审查的要求,为了响应这一呼声,ICANN 同意继续推进加强 ICANN 问责制的流程。由于相关方均同意通过跨社群工作组来推进这一流程,社群便要求针对董事会将如何处理跨社群工作组提出的建议得出定论,他们非常担心董事会可以将自己不同意的工作组建议丢弃或对其进行修改。鉴于社群采纳了跨社群工作组模型(包括董事会联络人),董事会希望能在整个流程中持续与所有参与者展开对话,共同提出建议并就每一条建议达成广泛共识。

      董事会听取了社群的顾虑,随后提出了这些原则,旨在为董事会将如何考虑加强 ICANN 问责制跨社群工作组提出的共识性建议提供指导。这些原则均是仿照 GNSO 和 ccNSO 政策制定流程要求而提出的,是董事会对问责制工作的贡献。

      采纳这些原则不会对 ICANN 造成任何此时此刻可预见的财务和资源影响。此决定亦不会给 DNS 的安全性、稳定性和灵活性带来任何预期影响。

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

    5. 感谢奥尔加·马德鲁加-福蒂女士 (Olga Madruga-Forti) 为 ICANN 董事会做出的贡献

      鉴于奥尔加·马德鲁加-福蒂在 2012 年 10 月 18 日被提名委员会任命为 ICANN 董事会成员。

      鉴于奥尔加于 2014 年 10 月 16 日结束了其在 ICANN 董事会的任期。

      鉴于奥尔加曾担任以下委员会的成员:

      • 审计委员会
      • 全球关系委员会
      • 管理委员会
      • 新 gTLD 项目委员会

      兹此发布第 2014.10.16.17 号决议:董事会对奥尔加·马德鲁加-福蒂在任期内所做的工作深表感谢,并祝愿她未来在 ICANN 社群内外的工作和生活一切顺利。

    6. 感谢塞巴斯蒂安·巴肖莱 (Sébastien Bachollet) 为 ICANN 董事会做出的贡献

      鉴于塞巴斯蒂安·巴肖莱在 2010 年 12 月 9 日被一般会员社群任命为 ICANN 董事会成员。

      鉴于塞巴斯蒂安于 2014 年 10 月 16 日结束了其在 ICANN 董事会的任期。

      鉴于塞巴斯蒂安曾担任以下委员会和工作组的成员:

      • 财务委员会
      • 结构改进委员会
      • 公众与利益相关方合作委员会
      • 会议战略工作组

      兹此发布第 2014.10.16.18 号决议:董事会对塞巴斯蒂安·巴肖莱在任期内所做的工作深表感谢,并祝愿他未来在 ICANN 社群内外的工作和生活一切顺利。

    7. 感谢比尔·格雷厄姆 (Bill Graham) 为 ICANN 董事会做出的贡献

      鉴于比尔·格雷厄姆在 2011 年 6 月 23 日被通用名称支持组织任命为 ICANN 董事会成员。

      鉴于比尔于 2014 年 10 月 16 日结束了其在 ICANN 董事会的任期。

      鉴于比尔曾担任以下委员会和工作组的成员:

      • 审计委员会
      • 全球关系委员会
      • 管理委员会
      • IANA 委员会
      • 新 gTLD 项目委员会
      • 风险委员会
      • 结构改进委员会
      • 董事会-GAC 建议实施工作组

      兹此发布第 2014.10.16.19 号决议:董事会对比尔·格雷厄姆在任期内所做的工作深表感谢,并祝愿他未来在 ICANN 社群内外的工作和生活一切顺利。

    8. 感谢希瑟·德莱顿为 ICANN 董事会做出的贡献

      鉴于希瑟·德莱顿在 2010 年 6 月 25 日被任命为 GAC 的 ICANN 董事会联络人。

      鉴于希瑟于 2014 年 10 月 16 日结束了其在 ICANN 董事会的任期。

      鉴于希瑟曾担任以下委员会的联络人:

      • 新 gTLD 项目委员会

      兹此发布第 2014.10.16.20 号决议:董事会对希瑟·德莱顿在任期内所做的工作深表感谢,并祝愿她未来在 ICANN 社群内外的工作和生活一切顺利。

resolutions-16oct14-zh.pdf  [338 KB]

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