Skip to main content

合作与共识:了解 EPDP 的工作

今年 8 月,快速政策制定流程第 2 阶段团队提交了其第 2 阶段最终报告,该报告概述了针对非公开通用顶级域 (gTLD) 注册数据的标准化访问/披露系统 (SSAD) 的 22 项建议,以及与 SSAD 无关的其他建议。

这份报告的形成绝非一蹴而就,其中包含了每位参与人员的奉献和决心,我希望在此向他们表示感谢。报告中提出的大部分建议要么获得了充分共识,要么在指派方面达成了一致认可,这证明该工作组有能力按照多利益相关方参与且采取自下而上的方式,协作并制定解决方案。

2018 年 7 月,根据 ICANN 董事会采纳 gTLD 注册数据临时规范的决议,GNSO 理事会发起并确立了关于 gTLD 注册数据临时规范的快速政策制定流程 (EPDP),这是 ICANN 历史上的第一个 EPDP。在过去的两年中,EPDP 团队不遗余力地制定政策草案,以便让注册目录服务 (RDS) 符合欧盟的通用数据保护条例 (GDPR)。

EPDP 的目标是起草一项让 ICANN 遵守相关法律的政策。最终报告的编制工作成效显著;该工作组能够在这么短的时间内完成这项工作,既令人瞩目,又值得赞扬!

上个月,GNSO 理事会接受了最终报告的建议,现在该理事会正在准备一份报告,以供 ICANN 董事会审议。此外,在其解决方案中,GNSO 理事会还请求在递交 GNSO 理事会建议报告期间向董事会咨询,以讨论提议的 SSAD 的财务可持续性和各种少数群体声明中所表达的一些关注问题。

与此同时,ICANN 组织正在制定一个拟议的运营设计阶段 (ODP),该阶段将作为政策和实施生命周期的一部分,旨在按照透明的方式,帮助董事会为审议 GNSO 理事会批准的共识性政策建议做准备。在此阶段,ICANN 组织将从风险、预期成本、资源需求和实施的预计时间表等方面,评估拟议的政策建议的影响。在董事会决定是否采纳相关政策建议之前,社群将有机会就评估情况提供反馈意见。

ICANN 组织会继续就一些尚未解决的问题,向欧洲数据保护理事会 (EDPB) 寻求更明确的法律澄清。10 月 2 日,我已致函三位欧盟委员会总干事,向他们介绍了迄今为止取得的最新进展,并强调了在以下方面,他们的反馈至关重要:针对披露非公开注册数据,制定一个集中化、可预测性的解决方案。

这并非是 ICANN 组织首次向欧洲数据保护机构 (DPA) 征求反馈。2020 年 2 月 14 日,我们曾与比利时数据保护机构举行会晤,并就统一访问模型 (UAM) 以及该工作组在 SSAD 方面取得的积极进展,展开了富有成效的讨论。关于怎样确保 EPDP 提议的混合模型可以让 ICANN 遵守 GDPR,EDPB 持续提供的反馈意见、见解及其持续的参与至关重要。

该社群在此方面表现出色,将多利益相关方模型推向了极致,进而实现了最终目标。尽管 EPDP 的成员们亟须稍作休息,但 ICANN 组织将就提议的模型,继续向欧洲利益相关方征求意见。

Comments

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