Skip to main content
Resources

批准的决议 | 新 gTLD 计划委员会会议

本页面还提供其他语种:

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

 

  1. 认可议程
    1. 批准 NGPC 会议记录
  2. 主要议程
    1. 北京和德班 GAC 建议的剩余事项
    2. 域名冲突讨论
    3. 字符串相似性讨论
    4. 其他事项

 

  1. 认可议程:

    1. 批准 NGPC 会议记录

      第 2013.09.28.NG01 号决议:理事会批准了 2013 年 8 月 13 日和 2013 年 9 月 10 日的新 gTLD 计划委员会会议记录。

  2. 主要议程:

    1. 北京和德班 GAC 建议的剩余事项

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

      鉴于 GAC 在 ICANN 第 47 届德班会议期间举行了会议,并于 2013 年 7 月 18 日发布了公报(下称"德班公报")。

      鉴于 NGPC 制定了一张计分卡,用于回应分别于 2013 年 6 月 4 日和 2013 年 9 月 10 日在北京公报和德班公报通过的 GAC 建议。

      鉴于 NGPC 制定了另一张计分卡,用于回应北京公报和德班公报 GAC 建议的特定剩余事项。

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

      第 2013.09.28.NG02 号决议:NGPC 采纳了"北京和德班 GAC 建议的剩余事项:更新和行动"(2013 年 9 月 28 日),作为本决议的附录 1 [PDF, 94 KB] ,用于回应计分卡上北京公报和德班公报 GAC 建议的剩余事项。

      第 2013.09.28.NG02 号决议的理由

      根据《ICANN 章程》第 XI 条第 2.1 款 <http://www.icann.org/zh/about/governance/bylaws-XI>,GAC 可以"直接将问题提请理事会,提请方式既可以是提出意见或事先建议,也可以是就某项行动、新政策的制定或现有政策的修订提出具体建议。"GAC 在 2013 年 4 月 11 日发布的北京公报和 2013 年 7 月 18 日发布的德班公报上向理事会提出了有关新 gTLD 计划的建议。《ICANN 章程》要求理事会在制定和采纳政策的过程中考虑有关公共政策问题的 GAC 建议。如果理事会决定采取不符合 GAC 建议的措施,则必须通知 GAC 并解释为什么不接受其建议。然后,理事会和 GAC 需要本着真诚合作的态度找到一个双方都可以接受的解决方案。如果找不到这样的解决方案,理事会必须在其最终决策中解释不采纳 GAC 建议的原因。

      NGPC 先前已经解决了北京和德班 GAC 建议中的一些事项,但有些事项 NGPC 仍在继续努力解决。目前,NGPC 正被要求考虑接受 2013 年 9 月 28 日计分卡上剩余的北京和德班 GAC 建议事项。

      作为对 GAC 建议考虑的一部分,2013 年 4 月 18 日,ICANN 公布了北京 GAC 建议并正式向申请人告知了该建议 <http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en>,同时依据《申请人指南》第 3.1 单元启动了为期 21 天的申请人回应期。此外,2013 年 8 月 1 日,ICANN 公布了德班 GAC 建议并正式向申请人告知了该建议 <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>,同时依据《申请人指南》第 3.1 单元启动了为期 21 天的申请人回应期。要查看完整的申请人回应,请访问:<http://newgtlds.icann.org/en/applicants/gac-advice/>

      另外,在 2013 年 4 月 23 日,ICANN 设立了一个公众意见论坛,就 NGPC 应如何处理北京 GAC 关于保护各大类新 gTLD 字符串的建议征询意见<http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm>。除机构群体关于 ICANN 如何实施北京公报中的 GAC 保护建议以外,NGPC 在思考如何回应 GAC 建议的剩余事项时,还对申请人回应进行了考量。

      在申请人回应期内,一些申请人表示他们与受影响的各方进行了对话,预计能够就相关问题达成协议。一些申请人表示,他们提出了额外的保护措施来解决相关政府的顾虑,但不能确定能否达成和解。这些申请人要求,即使不能在相关方之间达成一致,ICANN 理事也应允许他们继续申请。此外,已经就申请人和相关政府是否有机会就 GAC、ICANN 理事会和 ICANN 工作人员之间的谈话发表意见进行了咨询。也已申请让 GAC、NGPC 和 ICANN 工作人员在做出关于采取任何额外保护措施的决定前与申请人协商。

      其他申请人认识到了政府在多利益主体模式中的重要性,但是建议 NGPC 禁止政府对通过多利益主体流程采纳的 ICANN 政策行使否决权。

      另外,机构群体的一些成员反对 NGPC 接受 GAC 关于保护措施的建议。反对者普遍表示,该建议属于意料之外的新政策,违背了自下而上流程的概念,他们对此有所顾虑。他们还表示,保护措施过于模糊并且定义不充分,因此不太可能得到实施。

      作为审议的一部分,NGPC 审核了以下材料和文档:

      在起草对北京和德班 GAC 建议的剩余事项的回应时,NGPC 考虑了申请人提交的意见、公报中传达的 GAC 建议和 AGB 中制定的程序。采纳随附计分卡提供的 GAC 建议将有助于处理 GAC 建议,并且处理的方式允许让尽量多的新 gTLD 申请可以尽快得到进一步审批。

      批准此项决议不会产生可预见的财务影响,但是一旦通过批准将进一步分析所讨论的可能解决方案的财务影响。批准此项决议不会产生任何与 DNS 相关的安全性、稳定性或灵活性问题。

      作为 ICANN 组织管理职能的一部分,2013 年 4 月 18 日,ICANN 公布了北京 GAC 建议并正式向申请人告知了该建议。同样,2013 年 8 月 1 日,ICANN 公布了德班 GAC 建议并正式向申请人告知了该建议。这两次公布情况均依据《申请人指南》第 3.1 单元启动了为期 21 天的申请人回应期。

    2. 域名冲突讨论

      未达成任何决议。

    3. 字符串相似性讨论

      未达成任何决议。

    4. 其他事项

      未达成任何决议。

resolutions-new-gtld-28sep13-zh.pdf  [229 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."