摘要

  • GAC在5月11日来函中，把目标表述为推动法人注册数据的收集和公开，并在认为工作自2022年起未有进展后要求确认时间表。
  • ICANN在8月24日答复，称Phase 2A预计可在FY2027启动；同一封信明确指出，现行政策只允许而不要求区分法人和自然人，最佳实践也不会形成新的合同义务。

一条往来函件，出现了两个不同的“实施”对象。

2026年5月11日，Governmental Advisory Committee主席Nicolas Caballero致函ICANN董事会主席Tripti Sinha。GAC认为，自董事会于2022年3月通过EPDP Phase 2A建议后，为法人注册数据的收集和公开创造条件的工作一直没有推进。信中重申了GAC的政策立场：签约方应当收集并公开法人的数据。GAC要求确认实施时间表，并表示愿意参加Implementation Review Team。

8月24日的回函提供了一个有条件的时间点。ICANN org表示，在使用专门实施资源的现有项目完成后，预计可以在FY2027开始Phase 2A实施。ICANN于8月25日公开这封信。

然而，回函的治理价值不只在日期。董事会主席指出，Phase 2A团队决定不修改法人和自然人注册数据区分方面的现有Consensus Policy要求。现行Registration Data Policy允许注册局和注册商在判断是否适用RDDS遮蔽规则时，考虑数据是否属于法人或是否包含个人数据，但不要求这样做。Phase 2A将形成的最佳实践，也不会给签约方带来合同义务。

因此，问题不能只概括为“排队四年”。GAC希望实现的公开政策结果，与当前等待实施的已通过建议，并不是同一个范围。

2022年决议中的动词

ICANN董事会在2022年3月10日通过了四项建议。第一项要求创建一个或多个字段，用于帮助区分法人和自然人的注册数据，以及/或者个人与非个人数据；选择进行区分的签约方可以使用这些字段。

第二项建议选择按主体类型区分的签约方遵循报告中的指引。第三项涉及未来如果由相关控制者和处理者在ICANN内部制定GDPR行为准则，应当考虑这些指引。第四项针对选择在公开RDDS中发布基于注册人或注册记录的电子邮件地址的签约方，要求其评估EPDP团队取得的相关法律意见。

这不是“什么都没有通过”。董事会明确指示总裁兼首席执行官或其指定人员制定并执行实施计划。ICANN org必须落实获批建议，其中包括技术字段工作。签约方是否选择使用字段，与ICANN是否应完成字段，并不是同一个问题。

边界同样写在2022年的决定中。董事会说明，这些建议不会给签约方带来新的义务。它还指出，处于Registry Agreement、Registrar Accreditation Agreement和Consensus Policies之外的指引与最佳实践，不是合同要求，ICANN Contractual Compliance也就没有依据因未采纳这些建议而采取合同执法行动。

8月24日回函沿用了这套结构。建议1、2和4组成面向签约方的最佳实践交付物；建议1和3还要求ICANN org开展工作。建议1同时出现，是因为它既包含指引，也包含技术协调。这种项目分组不能改变每一部分原有的效力。

现行政策没有把“法人”当成公开开关

Registration Data Policy分别规定收集、传输、托管、公开、遮蔽、同意和依法披露。每个环节可能使用相同的数据，却承担不同的判断。

第9.2.1节规定，在为遵守适用法律而必须遮蔽个人数据时，注册局和注册商必须采用相应规则；在特定其他情形下，也可以采用。决定是否适用时，它们可以考虑注册数据是否涉及法人、是否包含个人数据以及相关地理位置，但政策明确说并非必须考虑。

法人记录不等于“全是非个人数据”。公司域名可能列出雇员、创办人、外部律师或者负责域名管理的自然人的姓名、电话和邮箱。主体类别只能说明记录的一项属性，无法替代逐字段判断。

Registrant Organization字段展示了现有控制方式。注册商必须让Registered Name Holder有机会填写该字段，并在其提供时收集；同时要告知，只有在持有人同意时，该组织值才会在RDDS中公开，而且该组织将被视为Registered Name Holder。持有人同意后，注册商必须公开；不同意时，注册商可以依政策遮蔽。

这不是所有法人记录的统一答案，却说明了公开决定所需的证据链：具体字段是什么、由谁提供、是否含有可识别自然人的数据、适用哪一项规则、是否涉及同意，以及谁对最终决定负责。单独的类别值不能完成这条链。

技术字段解决表达，不解决授权

董事会答复称，第二组工作需要与技术社区协调，审查在Extensible Provisioning Protocol中加入区分字段，并形成更新后的RDAP Profile。

这项工作有真实价值。共同的数据模型可以规定允许值、未知状态、未区分状态、更新时间和更正路径，避免不同供应商分别使用自由文本、含义不明的布尔值或者无法追溯的推断。EPP和RDAP之间的稳定表达，也能减少数据在系统边界上的语义丢失。

但字段本身没有独立授权。它不能决定谁必须填写，不能证明分类依据可靠，也不能因为EPP传输了某个值，就要求RDAP公开相关数据。RDAP Profile定义如何表示信息，不会取代Registration Data Policy、适用法律或者负责处理数据的一方。

技术标准能够让已经获得授权的区分变得可互操作；不能把尚未通过的政策结果变成合同命令。

实施计划需要一张范围对照表

在编写字段之前，ICANN应把五个层次并列公开。

第一层是GAC的政策立场：来源是哪封信或哪份公报，性质是咨询意见，目标是何种公开程度。第二层是获批的Phase 2A建议：董事会决议要求ICANN org交付什么，哪些内容对签约方仍为自愿。第三层是现行合同政策：哪条规则负责收集、遮蔽、同意、公开和披露。第四层是EPP/RDAP技术工作：它只负责怎样表示和传递。第五层是单条记录的决定：由哪个负责任的主体依据何种政策和法律作出。

每一层还应标明文本版本、责任人、实施状态、效力和正式变更路径。若GAC希望把区分变成普遍义务，对照表应指向能够修改政策的程序；若RDAP Profile已经完成，也必须说明这不代表所有签约方已经采用，更不代表更广泛的公开目标已经实现。

这张表不会替任何一方赢得隐私争论。它的作用更基础：防止“实施”一词掩盖尚未作出的决定，也让公众能够针对真正获批的项目检查进度。

FY2027只表示可能开始

回函把启动与现有项目、专门资源、运营计划和预算周期联系起来，并邀请GAC继续参与FY2028规划。公开记录尚未给出完成日期、最终字段设计、最佳实践文本或采用率。

项目问责仍然可以立即开始。ICANN可以说明哪些依赖已经解除、由谁负责、每个交付物对应哪项建议、时间顺序为什么变化。GAC可以继续主张新的政策结果。GNSO可以处理需要正式政策权力的改变。技术社区可以把表达定义清楚。注册局和注册商则要在每一条实际记录上承担其合同与法律责任。

这些角色可以合作，却不能互相替代。咨询参与不是合同修订，董事会要求ICANN实施不是对每一家注册商的新命令，字段不是披露许可，项目状态也不是政策文本。

ICANN已经在8月24日回函中划出边界。下一项治理测试，是Phase 2A在进入文档、数据模型和产品系统后，是否仍然保留这条线。

来源

  1. ICANN往来函件索引
  2. Tripti Sinha致Nicolas Caballero，2026年8月24日
  3. Nicolas Caballero致Tripti Sinha，2026年5月11日
  4. ICANN董事会2022年3月10日Phase 2A决定
  5. EPDP Phase 2A最终报告
  6. 提交董事会审议的Phase 2A建议说明
  7. ICANN Registration Data Policy
  8. ICANN RDAP资源