Skip to main content

ICANN 组织的工程部和集中化域资料服务 (CZDS) 概览

在近期举办的 ICANN69 届会议筹备周中召开的“ICANN 组织高管团队问答会”期间,我被问到工程和信息技术部如何确定整体工作重点,特别是集中化域资料服务 (Centralized Zone Data Service, CZDS) 的工作进展如何。在给大家介绍 CZDS 的最新动态之前,我想解释一下工程和信息技术部 (E&IT) 确定项目重点的方式。

E&IT 部门是 ICANN 组织的一个基础“服务提供商”。鉴于各套系统无法完全遵守组织所确定的职能界限,E&IT 部门使得我们能够方便地识别各种跨职能工作所带来的影响。鉴于此,E&IT 部门团队使用一套完整的合作式流程,搜集各个系统的需求,并确定工作重点。ICANN 组织的高级领导人每年需要针对所属职能的当前和未来的 E&IT 相关项目需求进行两轮评估。这些项目可以相对简单(例如:计算机、网络和存储基础设施的优化),也可以相对复杂(例如:符合要求的软件系统定制化编程),以及为了配合这类系统进行的基础设施优化工作。这个流程包括从各个团队搜集反馈意见、将各种项目提案和组织明示战略相对应、理解跨职能工作的依赖条件和相互影响、考虑社群提供的反馈、决定各项请求的主次先后。此举将使得我们对 ICANN 内部各项职能的 E&IT 需求确定一套有序的清单。

然后,我们将针对可用资本(基于社群已经审核且 ICANN 董事会已经批准的预算)和 E&IT 部门的能力(基于尚未承诺的 E&IT 人力资源,包括外包资源)分析每个项目的需求。这些都是我们在确定每个阶段(从 1 月至 6 月和从 7 月至 12 月)期间有多少项目仰赖于 E&IT 部门时的主要因素。此举帮助我们确定需求订单中的具体事项。

E&IT 项目的确定清单也被称为“固定交付流水线”。每个阶段的“固定交付流水线”都将由 ICANN 高级副总裁们和首席执行官先后进行审核和批准,最终确定一套预期交付事项。针对这套计划做出的任何调整,包括项目增减,都将由首席执行官进行审核。

为了促进“固定交付流水线”的内部组织和协调,E&IT 部门的工作被划分为了七个工作阶段。前六个工作阶段是相对独立、没有重复项目的,而所有的工作阶段都将以不同状态或形式最终汇总至第七个工作阶段(借助 IT 基础设施)。这七个工作阶段包括:

  1. 社群交流:促进与 ICANN 社群展开交流相关的工作。例如,支持 ICANN 英才计划、ICANN 社群组织和差旅支持项目的各种系统。
  2. 社群合作:主要与 ICANN 组织、支持组织 (Supporting Organizations, SO) 和咨询委员会 (Advisory Committees, AC) 使用的各种工具和网站相关的工作。信息透明度倡议 (Information Transparency Initiative, ITI) 就属于这个类型。
  3. 签约方:与注册管理机构和注册服务机构的交易相关的各项支持工作,包括域名服务门户 (Naming Services portal, NSp)。
  4. 技术服务:与 ICANN 组织使用和/或 ICANN 社群借用的各种系统相关的工作,旨在确保签约方能够履行签约义务。《服务水平协议》监控系统 (Service Level Agreement Monitoring, SLAM)、域文件访问和 CZDS 等系统都属于这个类型。
  5. 互联网号码分配机构 (Internet Assigned Numbers Authority, IANA) 的服务:与社群和 IANA 团队用来执行 IANA 职能(包括根区管理)的系统相关的工作。
  6. 员工服务:与服务于 ICANN 组织的各类系统相关的工作,包括企业资源规划 (ERP) 的各项职能,例如:人力资源、财务部、企业内网、电子邮件、通话系统、Slack 内部消息,等等。
  7. 借助 IT 基础设施:与上述列举的所有利益相关方所使用的系统和服务相关的工作。这些系统包括:Zoom、数据中心、云技术、信息安全、ICANN 管理的根服务器 (ICANN Managed Root Servers, IMRS) 等等。

了解工作重点确定的流程后,我想针对社群持续关注的 CZDS 进行详细介绍。

几年以前,我们对 CZDS 进行了重新定位,使其成为一套结合 Java 和 Salesforce 的平台。Java 用于前端的 ICANN 社群事务应对请求人,Salesforce 则用于后端的签约方批准人(这项功能也被整合进入了 NSp 之中)。该工作于 2019 年 1 月完成。尽管这是个很好的开始,但还需要解决几个额外事项,才能使得 CZDS 执行安全与稳定咨询委员会 (Security and Stability Advisory Committee, SSAC) 于 2017 年提出的 SAC097 中的建议。

E&IT 部门下属与 CZDS 相关的工作涉及第三个工作阶段(签约方)和第四个工作阶段(技术服务)。以下是下阶段(即 2021 年 1 月至 6 月)期间与这些工作阶段相关的“固定交付流水线”事项,按照项目重点、资源分配和简短介绍进行列举。

E&IT 固定交付流水线

技术服务

  • 《服务水平协议》监控系统 (SLAM) 正在进行重大调整,为注册管理机构改善监控绩效、安全和衡量标准。SLAM 系统是 ICANN 技术服务系统的骨干。
    • “注册服务机构监测 (Registrar Watch)”项目将为注册服务机构提供 SLA 监控,使得 ICANN 能够按照《注册服务机构认证协议 (Registrar Accreditation Agreement, RAA)》的规定监督注册服务机构提供的服务。
    • 改进 ICANN 的监督系统应用程序编程接口 ( Monitoring System API, MoSAPI) 将支持《注册数据访问协议 (Registration Data Access Protocol, RDAP)》的监控,使得 ICANN 能够在监控功能启用后,向签约方提供详细的 RDAP 信息。这将有利于注册管理机构纳入更多 SLA 监控衡量标准。
    • 针对注册报告界面 (Registration Reporting Interface, RRI) 的改进将使得 ICANN 的合同合规部门能够更好地应对可能发生的注册服务机构数据托管代理 (Registrar Data Escrow Agent, DEA) 通知问题。

签约方

  • 针对域名服务门户 (NSp) 的工作还在继续。
    • 我们正在重新构建与技术服务系统的整合事项,这将使得我们不再使用传统的合规平台 (Kayako),节省认证许可费用,提高合规团队的工作效率,改善合规案例报告人的用户体验。
    • NSp 合规将引入一项新功能,使得报告人能够提交多个(批量)合规案例,并对余下的整合事项负责。
    • 在 2021 年 6 月至 7 月这个时段内,本团队将开始开发 CZDS v3.0 版,推行 SSAC 提出的一项建议,即针对域文件中已经批准的请求进行自动延期。

总而言之,自 2017 年 SAC097 获得 ICANN 董事会批准以来,CZDS 的相关工作一直是我们的一项工作重点。CZDS 已经经历了多次调整。但这些调整主要涉及 CZDS 使用的基础设施,终端用户并没有办法看到。此外,与社群进行的协商和与 ICANN 组织内部进行的讨论均导致其他项目被提到了更靠前的议事日程之上。但根据目前的工作重点和限制,在接下来的一段时间内,工程部的工作阶段显示 CZDS 的工作将于 2021 年中期再次启动。

E&IT 团队充分理解社群希望看到 CZDS 项目能够得到更快交付,但我们也在考察面对资金和人力资源的限制,如何在短期内实现产能最大化。从短期和长期来说,Java 的资源相对比较容易获取,但涉及 NSp 工作的 Salesforce 人才已被证明更难识别和招聘。

随着我们进入下阶段的工作,我将期待着继续向社群通告最新动态。与此同时,我们要衷心感谢大家的理解与耐心。

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