Skip to main content
Resources

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

本页面还提供其他语种:

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

 

  1. 认可议程
    1. 批准 NGPC 会议记录
  2. 主要议程
    1. 字符串相似性更新
    2. BGC 关于复议申请 13-5 的建议
    3. GAC 德班公报 – 计分卡
    4. GAC 北京公报 – 计分卡
    5. GAC 北京公报 – 类别 1
    6. ALAC 关于优先处理字符串争用中群体申请的声明
    7. ALAC 关于群体优先评估中机构群体专业知识的声明
    8. 其他事项

 

  1. 认可议程:

    1. 批准 NGPC 会议记录

      兹发布第 2013.09.10.NG01 号决议:理事会批准了 2013 年 7 月 13 日和 7 月 17 日新 gTLD 计划委员会会议记录。

  2. 主要议程:

    1. 字符串相似性更新

      未达成任何决议。

    2. BGC关于复议申请 13-5 的建议

      鉴于针对新 gTLD 计划公布了字符串相似性审核小组的结果(即将 .hotels 和 .hoteis 申请归入字符相似性争用集)后,Booking.com B.V.(下称"Booking.com)提出复议申请(申请 13-5),要求复议 ICANN 工作人员于 2013 年 2 月 26 日采取的行动。

      鉴于 BGC 考虑了复议申请 13-5 中提出的问题。

      鉴于 BGC 以 Booking.com 尚未针对复议提供适当理由为由,建议否决复议申请 13-5。

      兹发布第 2013.09.10.NG02 号决议:新 gTLD 计划委员会采纳 BGC 关于复议申请 13-5 的建议,详情请访问 http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB]。

      第 2013.09.10.NG02 号决议的理由

      ICANN 章程要求理事会管理委员会评估复议申请并为理事会提供建议。请参阅《ICANN 章程》第 IV 条第 3 款。在这种情况下,新 gTLD 计划委员会(下称"NGPC)被赋予理事会权力后,审查并全面考虑了 BGC 关于复议申请 13-5 的建议,而且认定该分析合理。

      由 BGC 审查复议流程并向理事会提出建议,供理事会/NGPC 审批,选择这一做法对 ICANN 的透明度和问责制有积极影响。它为机构群体提供了一个途径,确保工作人员和理事会的行为符合 ICANN 政策、章程和组织条例。

      申请要求撤销字符串相似性审核小组(下称"小组)于 2013 年 2 月 26 日作出的决定,即将 Booking.com 对 .hotels 申请与 .hoteis 归入同一争用集。具体而言,Booking.com 声称其申请的 .hotels 字符串可在根区域中与所申请的 .hoteis 字符串共存,而不会引起混淆。因此,.hotels 不应与 .hoteis 归入同一争用集。

      申请要求考虑以下事项:(1) 小组对 Booking.com 的申请进行字形相似性审核时是否违反了任何政策或流程;以及 (2) 在将关于 .hotels/.hoteis 的决定作为"一项建议提供给 ICANN且 ICANN 最终决定接受此建议的基础上,NGPC 能否推翻小组的此项决定。

      BGC 表示,Booking.com 在 2013 年 3 月 28 日提交过一份类似的复议申请,但由于遵照 ICANN 的文献信息披露政策的要求尚未制定完成,该申请被暂且搁置。因此,该申请需追溯到最初提交日期,应根据在 2012 年 12 月 20 日至 2013 年 4 月 10 期间有效的章程进行评估。

      鉴于第一个问题,BGC 审核了申请及其附件中陈述的理由,认为 Booking.com 未就工作人员行动的复议申请作出充分说明,因为并没有指明工作人员违反的任何政策或流程。BGC 表示,Booking.com 没有提出未遵守《申请人指南》中规定的字符串相似性审核流程,或者 ICANN 工作人员在接受小组决定将 .hotels 和 .hoteis 归入同一争用集时违反了任何 ICANN 既有的政策。相反,Booking.com 希望取代原本用于评估字形相似性的审核方法,而不是《申请人指南》第 2.2.1.1.2 款规定的方法,并要求 BGC(以及从理事会到新 gTLD 计划委员会)根据其提议的方法重审 2013 年 2 月 26 日作出的决定。BGC 认为,由于复议流程不可用作重审评估小组决定的机制,因此复议理由不充分。

      对于 Booking.com 提出的异议,即 2013 年 2 月 26 日作出的决定没有提供任何实质信息,例如 Booking.com 语言专家的意见或其他"驳斥可能使用户在 .hotels 和 .hoteis 之间产生混淆的错误争用的信息,BGC 认为字符串相似性审核流程中并没有规定申请人需提交其他信息。由于 ICANN 在对 Booking.com 关于字符串相似性审核相关文档的申请回复中已向其做出了解释,因此便根据《申请人指南》中的方法并辅以小组的流程文件进行了审核工作;该流程不允许考虑其他意见。BGC 表示,Booking.com 对于该方法是否会影响字形相似性结果的异议并不表示 ICANN(包括进行字符串相似性审核的第三方)在做出决定时违反了任何政策(也不能断定决定是错误的)。

      鉴于第二个问题,Booking.com 表明理事会(下至 NGPC)能够推翻小组对 .hotels/.hoteis 的决定,因为小组只不过是"向 ICANN 提供建议 并且 ICANN 最终决定接受了这一建议,BGC 认为这是对字符串相似性审核流程的理解不到位造成的。因此,BGC 认定 Booking.com 提供的复议理由不充分。BGC 表示,所有申请的字符串均由小组根据《申请人指南》中规定的字符串字形相似性审核标准和方法予以审核。《指南》明确规定,当小组确定争用集后,ICANN 将立即通知申请人并在其网站上公布结果。(AGB,第 2.2.1.1.1 款。)不管传达的结果是"建议、"结果还是"报告,ICANN 始终明确表示信赖评估人员根据质量保证措施在新 gTLD 计划的初始评估阶段给出的建议。后续收到和考虑的 GAC 关于单复数字符串的建议不会改变根据字形相似性形成争用集的既定流程,因为根据《章程》要求,ICANN 理事会需要考虑 GAC 关于单复数字符串等公共政策问题的建议。BGC 认为,Booking.com 提议 ICANN 应对字符串相似性审核小组的结果进行实质性审核(而非采用流程测试),然后再最终确定争用集,实际上提出了一种不同的新流程。

      除以上所述,有关 BGC 的完整建议,请访问 http://www.icann.org/ en/groups/board/governance/reconsideration/recommendation-booking-01aug13-en.pdf [PDF, 117 KB],建议作为参考资料附件提交给理事会,以便为此决议提供支持,也应将其视为此理由的一部分。

      采纳 BGC 的建议不会对 ICANN 产生财务影响,并且不会对域名系统的系统安全性、稳定性和灵活性产生负面影响。

      此项决定体现了无需征询公众意见的组织管理职能。

    3. GAC 德班公报 – 计分卡

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

      鉴于在 2013 年 8 月 1 日,ICANN 公布了德班公报并正式向申请人告知了该建议 <http://newgtlds.icann.org/en/announcements-and-media/announcement-01aug13-en>,同时依据《申请人指南》第 3.1 单元启动了为期 21 天的申请人回应期。

      鉴于 NGPC 在 2013 年 8 月 12 日举行了会议,针对 GAC 通过德班公报向理事会传达的有关新 gTLD 计划的建议制定相应的回应计划。

      鉴于 NGPC 已对在为期 21 天的申请人回应期内收到的申请人回应进行了考量,并确定了附随的计分卡上的建议,其立场与德班公报中的 GAC 建议一致。

      鉴于 NGPC 制定了一张与 2011 年 2 月 28 日至 3 月 1 日于布鲁塞尔召开的 GAC 和理事会会议期间采用的、用以处理北京建议的计分卡相似的计分卡,用于回应德班公报中的 GAC 建议,并确定了 NGPC 在哪些问题上的立场与 GAC 建议一致,并将其标记为"1A事项。

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

      兹发布第 2013.09.10.NG03 号决议:NGPC 采纳"用于回应 GAC 德班公报的 ICANN 理事会新 gTLD 计划委员会计分卡(2013 年 9 月 10 日),该计分卡作为附录 1 附 [PDF, 119 KB] 于本决议,如计分卡所示用于回应德班公报中的 GAC 建议事项。

      第 2013.09.10.NG03 号决议的理由

      NGPC为什么要解决此问题?

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

      正在考虑的提案是什么?

      目前,NGPC 需要考虑接受随附的用于回应 GAC 德班公报的 ICANN 理事会新 gTLD 计划委员会计分卡(2013 年 9 月 10 日)中提出的 GAC 德班建议。如计分卡所述,大部分建议事项计为"1A,表示 NGPC 的立场与计分卡中所述的 GAC 建议一致。

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

      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/durban47。NGPC 在思考如何回应 GAC 建议时已适当考虑了申请人回应。

      机构群体有什么疑虑或提出了哪些问题?

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

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

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

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

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

      采纳申请人对德班公报中 GAC 建议的回应时,NGPC 考虑了申请人提交的意见、德班公报中传达的 GAC 建议和 AGB 中制定的程序。

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

      采纳随附计分卡提供的 GAC 建议时,将以尽量多地让新 gTLD 申请得到进一步审批的方式帮助处理 GAC 建议。

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

      批准此项决议不会产生可预见的财务影响。

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

      批准此项决议不会产生任何与 DNS 相关的安全性、稳定性或灵活性问题。

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

      2013 年 8 月 1 日,ICANN 公布了 GAC 建议并正式向申请人告知了该建议。同时依据《申请人指南》第 3.1 单元启动了为期 21 天的申请人回应期。

    4. GAC 北京公报 – 计分卡

      未达成任何决议。

    5. GAC 北京公报 – 类别 1

      未达成任何决议。

    6. ALAC 关于优先处理字符串争用中群体申请的声明

      未达成任何决议。

    7. ALAC 关于群体优先评估中机构群体专业知识的声明

      未达成任何决议。

    8. 其他事项

      未达成任何决议。

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