Skip to main content

GNSO 理事会通过快速政策制定流程 (EPDP) 团队发布的《gTLD 注册数据临时规范》最终报告

本页面还提供其他语种:

GNSO Council

洛杉矶——2019 年 3 月 4 日——通用名称支持组织 (Generic Names Supporting Organization, GNSO) 理事会于今天表决通过了快速政策制定流程 (Expedited Policy Development Process, EPDP) 团队发布的《通用顶级域 (gTLD) 注册数据临时规范 (Temporary Specification for gTLD Registration Data)》的《最终报告》。这份《最终报告》将提交给 ICANN 董事会供其考量。EPDP 团队的设立旨在确定《gTLD 注册数据临时规范》是否应当在未修改的情况下,或是在修改之后成为 ICANN 的一项共识性政策。

EPDP 团队发布的《最终报告》囊括了 29 条政策建议,主要应对了下列领域的问题:

  • 数据处理的目的;
  • 数据元素的搜集、转让和留存;
  • 用于公开显示的数据元素;
  • 用于编辑的数据元素;
  • 针对现有 ICANN 共识性政策的调整和/或审核;
  • 更新数据合法披露的合理请求;
  • 继续推行实施衔接工作,即在 EPDP 政策建议获得正式实施之前,签约方需要如何应对政策建议和《临时规范》到期后所需达到的要求。

在编制《最终报告》时,EPDP 团队审核了所有针对《初步报告》的公共评论,并将获得批准的调整纳入到了终稿之中。

公共评议

GNSO 理事会现已将 EPDP 团队发布的《最终报告》提交给了 ICANN 董事会供其考量。董事会采取任何行动前,ICANN 组织必须提供合理的机会,供所有相关方针对拟定通过的政策提出看法。

相应的,ICANN 组织于今天针对 EPDP 团队的《最终报告》启动了一轮公共评议期,评论截止时间为2019 年 4 月 17 日。现诚邀 ICANN 社群的成员和公众积极参与并建言献策。

EPDP 第 2 阶段工作

GNSO 理事会于今天提出意见,不反对 EPDP 团队启动章程中的第 2 阶段工作。这阶段的工作将涉及编制一套非公开注册数据的标准化访问系统,以及解决《临时规范》附件中列出的问题(即"社群后续行动中的重要问题")。此外,第 2 阶段的工作还将包括 EPDP 团队在第 1 阶段的考量中尚未解决并押后的一系列项目。EPDP 团队将在 ICANN64 届日本神户会议召开期间启动第 2 阶段的工作。GNSO 理事会目前正在针对 EPDP 第 2 阶段工作征召有意担任主席的人员。了解更多信息

EPDP 简介

2018 年 5 月 17 日,ICANN 董事会通过了《gTLD 注册数据临时规范》。董事会现已采取措施制定临时要求,使得 ICANN 及其签约方能够继续遵守现有 ICANN 合规要求和社群制定的有关 WHOIS 的政策,同时遵守欧盟 (European Union) 颁布的《通用数据保护条例 (General Data Protection Regulation, GDPR)》。这套《临时规范》根据《注册管理机构协议 (Registry Agreement, RA)》和《注册服务机构认证协议 (Registrar Accreditation Agreement, RAA)》中规定的临时政策流程而获得批准。《临时规范》获批后,董事会"应当立即执行 ICANN《章程》中确立的共识性政策制定流程。"针对《临时规范》启动的共识性政策制定流程应需要在 1 年期内实施推行。此外,工作范畴中还包括:讨论设立一套非公开注册数据的标准化访问系统。但只有在 EPDP 团队全面回复了 GNSO 理事会提出的一系列"关卡问题",且理事会不予反对后,有关标准化的访问系统的讨论工作才能得以展开。

ICANN 简介

ICANN 的使命在于确保全球互联网的稳定、安全与统一。在互联网上寻找另一个人的信息,您必须在您的电脑或其他设备中键入一个地址——可以是一个名称或是一串数字。这一地址必须是独一无二的,只有这样电脑之间才能互相识别。ICANN 则负责协调这些分布在全球各地的唯一标识符。ICANN 成立于 1998 年,是一家非营利公益型企业,其社群成员遍布全球各地。


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