Skip to main content

EPDP 第 2 阶段工作团队发布《最终报告》

本人代表通用顶级域 (gTLD) 注册数据临时规范快速政策制定流程 (EPDP) 团队,现高兴地宣布本团队第 2 阶段工作的《最终报告》现已出炉。

这份《最终报告》列出了 EPDP 团队针对非公开 gTLD 注册数据的标准化访问/披露系统 (System for Standardized Access/Disclosure, SSAD) 所提出的建议,以及针对所谓“重点 2”主题所提出的建议和结论,这包括:城市字段编辑等等事务。

最终报告精华内容

EPDP 团队同时针对集中式模型和分散式模型进行了审慎考量。集中式模型是指 ICANN 组织或其指定处理人负责处理请求和披露决定;分散式模型是指签约方(即 ICANN 授权注册服务机构和 gTLD 注册管理运行机构)负责处理请求和披露决定。本团队无法针对任一模型达成一致意见,因而提出了一套混合式模型,即所有请求将采取集中管理模式,而披露决定(至少在初步实施时)则将由签约方做出。

为了理解非公开注册数据披露请求的要求,EPDP 团队考量了许多问题,针对 SSAD 用户会面临的各类实际使用案例进行了探讨,确定了构建模块,并提炼出了常用主题用以草拟初步建议。EPDP 团队在对所获公共评议进行了详细审核和深入讨论后,在其《最终报告》中提出了 18 条 SSAD 相关政策建议,和 4 条针对“重点 2”的建议。

这 18 条 SSAD 相关政策建议广泛应对了以下领域:

  • SSAD 请求人的认证,包括政府实体
  • SSAD 请求必须达到的标准和内容
  • 响应要求
  • 必要的服务水平协议 (Service Level Agreements, SLA)
  • SSAD 处理自动化
  • SSAD 条款及条件
  • 登录、审核和报告要求
  • 设立 GNSO 常任委员会,即负责评估 SSAD 运营事务,向 GNSO 理事会提出改进建议的委员会

值得注意的是,EPDP 团队认为这 18 条 SSAD 相关建议是相互依存的,鉴于此,团队建议 GNSO 理事会将这些建议视为一个整体并将其呈交给 ICANN 董事会。

EPDP 团队还提出了 4 条涉及“重点 2”的建议,覆盖了以下主题:

  • 附属隐私/代理提供商的信息显示
  • 城市字段
  • 数据留存
  • 目的 2

后续步骤

GNSO 理事会将于世界协调时 2020 年 9 月 3 日 21:00 时针对 EPDP 第 2 阶段工作的《最终报告》召开一场网络研讨会,介绍报告详情。参会详情将在此处发布。

鸣谢

第 2 阶段工作《最终报告》的发布标志着 EPDP 团队的又一重大成就。第 2 阶段工作团队的 31 名成员和 19 名替补成员在过去一年间共召开了 74 场电话会议(每场会议时间均为数小时不等),并举行了多次面对面会议。

团队中每位成员透过多利益相关方流程给予的无私奉献、妥协意愿和工作承诺都推动着 EPDP 团队朝着实现最终目标又迈出了一大步。

我们要衷心感谢在公共评议期中不吝赐教的所有人。我们还要衷心感谢 ICANN 董事会和 ICANN 组织与我方的密切接触。他们为我们提供了宝贵的意见,为我们针对 SSAD 的考量提供了大量背景信息。

我们还要衷心感谢 EPDP 团队的支持员工,他们不辞辛劳、一步一步地促进我们实现目标。

最后我还不得不感谢第 2 阶段工作团队的主席亚尼斯·卡克林斯 (Janis Karklins),他自愿投入了大量时间,充分发挥其协调和领导才能,促使团队实现这一成就。

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