Skip to main content
Resources

获批决议 | 新 gTLD 项目委员会会议

本页面还提供其他语种:

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到:https://www.icann.org/resources/board-material/resolutions-new-gtld-2015-06-21-en

  1. 认可议程:
    1. 批准会议记录
  2. 主要议程:
    1. GAC 第 2 类保护建议 - 独家通用 TLD
    2. 董事会治理委员会关于 .doctor 的建议
    3. 逐步淘汰新 gTLD 项目委员会
    4. 二级双字符和国家/地区域名的简报
    5. 销售事宜的最新动态

 

  1. 认可议程:

    1. 批准会议记录

      第 2015.06.21.NG01 号决议:董事会新 gTLD 项目委员会 (NGPC) 批准 2015 年 4 月 1 日会议和 2015 年 4 月 25 日会议的会议记录。

  2. 主要议程:

    1. GAC 第 2 类保护建议 - 独家通用 TLD

      鉴于 GAC 在 ICANN 第 46 届北京会议期间举行了会议,并于 2013 年 4 月 11 日发布了公报("北京公报" [PDF, 238 KB])。

      鉴于 GAC 在北京公报上向 ICANN 董事会提出了有关新 gTLD 项目的建议:"出于符合公众利益的目的,应对表示通用语的字符串实行独家 注册使用"。此项 GAC 建议在 GAC 建议注册中的编号为 2013-04-11-Safeguards-Categories-2 ("第 2.2 类保护建议")。

      鉴于 GNSO 理事会正在考虑请求《问题报告》,以分析在新 gTLD 项目后续轮次中可能导致政策、原则和程序更改或调整的问题。

      鉴于 NGPC 针对如何处理第 2.2 类保护建议已得出了审议结果。

      鉴于根据董事会于 2012 年 4 月 10 日的授权,NGPC 正在代 ICANN 董事会处理所有与新 gTLD 项目相关的问题。

      兹此发布第 2015.06.21.NG02 号决议:为处理 GAC 第 2.2 类保护建议,NGPC 请求 GNSO 特别将符合公众利益目标的通用字符串的独家注册使用事宜纳入新 gTLD 项目后续轮次的政策工作中,并定期向董事会报告进度。此外,NGPC 指示总裁兼首席执行官或其指定人员采取如下行动:

      1. 对于在新 gTLD 项目本轮次中建议独家注册使用的其余申请人( "独家通用申请人"),继续启动其他新 gTLD 项目流程,包括但不限于:

        1. 安排字符串争用拍卖;以及

        2. 指示异议程序的争议解决服务提供商针对因等待 NGPC 作出第 2.2 类保护建议决议而被延缓的未解决程序尽快得出结论并发布专家裁决,尽管相关方已达成任何延缓这些程序的协议。

      2. 建议未争用字符串的独家通用申请人或在争用解决中胜出的独家通用申请人在合理有限时间内选择以下其一:

        1. 提交 "不再是独家通用 TLD"的变更请求,并签署当前的《新 gTLD 注册管理机构协议》;

        2. 继续作为独家通用 TLD 运营;鉴于此,他们的申请将被推迟到下一轮次的新 gTLD 项目并遵循下一轮次的规则,从而让 GNSO 有充足的时间制定有关独家通用 TLD 的政策建议;或

        3. 撤销申请并按照《申请人指导手册》退款时间表领取退款。

      3. 采取其他执行本决议的必要合理措施。

      第 2015.06.21.NG02 号决议的理由

      NGPC 目前的行动处理了政府咨询委员会 (GAC) 关于新 gTLD 项目建议中的未决事项。该行动属于 ICANN 董事会处理 GAC 向董事会所提建议的职责范围。根据《ICANN 章程》 第 XI 条第 2.1 款, GAC 可以 "直接将问题提请董事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议"。《ICANN 章程》要求董事会在政策制定和采纳中考虑 GAC 对公共政策问题的建议。如果董事会决定采取不符合 GAC 建议的行动,则必须通知 GAC 并解释为什么不接受其建议。然后,董事会和 GAC 需要本着真诚合作的态度找到一个双方都可以接受的解决方案。如果找不到这样的解决方案,董事会必须在其最终决定中解释不采纳 GAC 建议的原因。

      GAC 在 2013 年 4 月 11 日的北京公报中就新 gTLD 项目向董事会提出了建议。在北京公报中,GAC 向董事会提出建议: "出于符合公众利益的目的,应对表示通用语的字符串实行独家注册使用"( "第 2.2 类保护建议")。在当前新 gTLD 项目轮次中,GAC 确定了它认为是通用术语而申请人正在提议独家注册使用的不完整字符串列表。

      ICANN 恳请申请 GAC 第 2.2 类保护建议中确定的 gTLD 字符串的 186 名申请人予以回复,说明是否计划作为独家使用注册管理机构(即 "注册限制为单个人或实体以及/或者此人或实体的'关联方'",请参阅《注册管理机构协议》第 2.9c 节的规定)来运行所申请的 TLD。在这 186 名申请人中,目前已有 5 名申请人表示有意对申请的通用字符串进行独家注册使用。

      NGPC 目前的行动处理了 GAC 第 2.2 类保护建议,并为本新 gTLD 项目轮次中提议独家注册使用通用字符串的其余申请人提供了明确的方向。NGPC 的行动承认通用字符串的独家注册使用可能会引发政策方面的担忧,需要 GNSO 通过自下而上的政策制定流程给出意见。

      具体而言,NGPC 正指示总裁兼首席执行官在适当时启动或重新开始其他新 gTLD 项目流程,这些针对独家通用申请人的流程被搁置至今,直到 NGPC 处理了 GAC 第 2.2 类保护建议。例如,有些申请属于异议程序主题(根据《申请人指导手册》模块 3),被相关方或争议解决服务机构延缓执行,以等待 NGPC 对 GAC 第 2.2 类保护建议的决议结果。由于 NGPC 的行动,处理异议程序的争议解决服务提供商将收到指示 - 针对因等待 NGPC 作出第 2.2 类保护建议决议而被延缓的未解决程序尽快得出结论并发布专家裁决,尽管相关方已达成任何延缓这些程序的协议。此外,ICANN 将继续安排争用字符串(.DATA、.FOOD 和 .PHONE)申请的争用拍卖。

      NGPC 还请求 GNSO 特别将符合公众利益目标的通用字符串的独家注册使用事宜纳入新 gTLD 项目后续轮次的政策工作中,并定期向董事会报告进度。总裁兼首席执行官应向 GNSO 提供支持该请求所需的信息。

      此外,还指示总裁兼首席执行官建议未争用字符串的独家通用申请人,或在争用解决中胜出的独家通用申请人在与 ICANN 执行注册管理机构 协议方面作出选择。这类独家通用申请人必须在合理有限时间内选择以下其一:

      1. 提交 "不再是独家通用 TLD"的变更请求,并签署当前的《新 gTLD 注册管理机构协议》,包括禁止独家通用 TLD 的 "公益承诺"(PIC),即 "通用字符串"TLD 的注册管理执行机构不得在 TLD 中强加注册域名的资格标准,使注册仅限于 "单个人或实体以及/或者该人或实体的 "关联机构"(如注册管理机构协议 2.9(c) 节中定义)。 "通用字符串"是指 "由一个定义或描述通用类商品、服务、群体、组织或事物的词或术语组成的字符串,与其相对的是由可区分一种特定品牌商品、服务、群体、组织或事物的词或术语组成的字符串"。

      2. 继续作为独家通用 TLD 运营。鉴于此,他们的申请将被推迟到下一轮次的新 gTLD 项目并遵循下一轮次的规则,从而让 GNSO 有充足的时间制定有关独家通用 TLD 的政策建议。

      3. 撤销申请并按照《申请人指导手册》退款时间表领取退款。

      在考虑 GAC 建议的过程中,ICANN 在其网站上公布了 GAC 建议,并正式告知了申请人该建议,同时依据《申请人指导手册》第 3.1 单元启动了为期 21 天的申请人回应期。北京 GAC 的建议发布于 2013 年 4 月 18 日。要查看完整的申请人回应,请访问: http://newgtlds.icann.org/en/applicants/gac-advice/。 另外,在 2013 年 4 月 23 日,ICANN 设立了一个公众意见论坛 ,就 NGPC 应如何处理 GAC 关于保护各大类新 gTLD 字符串的北京建议征询意见。

      在过去两年,NGPC 召开了十几次会议,考量了 GAC 关于独家注册使用通用字符串的建议。在作出回应时,NGPC 考虑了所有的材料以及相关事实和信息,包括对 ICANN 应如何实施北京公报中的 GAC 保护建议的申请人回应和社群反馈。各位 NGPC 成员在制定决策时进行了 独立判断,并一致认为该决策符合 ICANN 的最佳利益。社群就 NGPC 是否应该以及如何实施 GAC 建议表达了不同的观点。在采取此项行动时,NGPC 考虑了以下来自社群评论的一些重大主题:

      • 社群应采取符合公众利益的关于独家通用字符串运营的政策制定流程。应通过多利益相关方流程来解决有关 "封闭式通用"TLD 的政策问题。

      • 所述的公众利益目标要求过于笼统,应明确其可执行性。NGPC 应将 GNSO 关于促进竞争、消费者选择、市场差异,以及地理区域和服务提供商多样化的理由作为针对此类肯 定、客观的陈述和结果的标准,从而明确定义 "公众利益"概念。

      • 如果申请人选择申请在其所从事行业内开展业务活动时封闭控制特定行业的通用词语,则保护措施非常重要。

      • 要求申请人证明其在独家注册使用通用字符串情境下的一些其他公众利益目标,可以推翻 ICANN 社群在自下而上的流程中蓄意作出的决策并提出新的评估标准。

      • 应采用《申请人指导手册》中规定的现状,以便在这次第一轮的申请中继续允许 "开放式"和 "封闭式"通用字符串注册使用,但这两种方式在启动后应接受 ICANN 的监督,确保权利所有者和消费者的利益受到保护。

      社群和申请人的评论突出了问题的复杂性,NGPC 在回应 GAC 建议时已考虑到这点。之前关于 "封闭式通用"gTLD 申请的公共评议期也体现了这些主题,具体可查看 2013 年 7 月 8 日的 公共评论摘要报告 [PDF, 407 KB]。 作为本次公共评议期的一部分,NGPC 请求 GNSO 提供指导。鉴于时间紧张, GNSO 理事会 [PDF, 249 KB] 指出当时不便提供正式的政策指导。GNSO 理事会指出: "虽然 GNSO 在考量新 gTLD 政策制定流程时没有明确考虑'封闭式通用'TLD 的问题,但我们记得之前已经考虑和讨论过限制新 gTLD 的问题。当时,GNSO 认为 ICANN 没有职责以任何方式限制 gTLD 的使用,而应该让新 gTLD 申请人提出各种模型,不论是开放式或封闭式,也不论通用与否。"

      在审议过程中,NGPC 审核了诸多材料,包括但不限于以下材料和文档:

      GAC 建议的采用有助于解决 GAC 关于新 gTLD 项目的建议,将对社群产生积极影响。通过此项决议不会产生任何可预见的财务影响。批准此项决议不会产生任何与 DNS 相关的安全性、稳定性或灵活性问题。 作为 ICANN 组织管理职能的一部分,ICANN 于 2013 年 4 月 18 日公布了北京公报并正式告知了申请人该建议。同时依据《申请人指导手册》 模块 3.1 启动了为期 21 天的申请人回应期。

    2. 董事会治理委员会关于 .doctor 的建议

      未达成任何决议。

    3. 逐步淘汰新 gTLD 项目委员会

      未达成任何决议。

    4. 二级双字符和国家/地区域名的简报

      该议项已从议程中删除。

    5. 销售事宜的最新动态

      未达成任何决议。

resolutions-ngpc-21jun15-zh.pdf  [172 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."