摘要

  • prop-173 第一版拟把普通 WHOIS、RDAP、网页和同类 API 查询纳入一份独立政策，在各入口展示同意提示，并为中央政策保留版本号、生效日期、修订历史和旧版存档。它目前仍只是提交 Policy SIG 邮件列表讨论的提案。
  • 草案要求响应标识政策并链接到当前网址，却不要求带上适用版本、生效时间或内容摘要。一个很短的“条款凭据”就能把长期保存的结果与查询当时的规则重新连起来。

先承认这份草案解决了什么

普通查询不等于批量镜像。网络工程师查一次地址登记，安全团队为处理事件查一个联系人，研究人员以低频方式核对资源，这些动作与下载大规模数据、建立替代数据库不是一回事。APNIC 已经有批量 Whois 使用协议，但用它含蓄覆盖所有普通查询，会让保存、组合、再发布和产品化的边界变得含混。

prop-173 官方状态页记录，第一版在 2026 年 8 月 17 日发到 Policy SIG 邮件列表，当前状态是“Published to Mailing List”。所查记录里没有秘书处影响评估、共识结论、通过决定或实施公告。因此，本文讨论的只能是草案将会怎样设计，而不是 APNIC 已经依据 prop-173 如何执法。

第一版文本把范围写得很具体：任何个人或系统，只要通过 WHOIS、RDAP、网页搜索或提供同类登记数据的 API 访问 APNIC 权威数据，就会进入政策范围；镜像或转介自其他注册机构的数据，仍受其权威来源的条款约束；高容量访问、重要数据摘取、镜像和替代数据库，继续走独立的批量渠道。

这一切有充分理由。草案明确允许路由政策分析、故障排查、资源持有人识别、反向 DNS、滥用处置和技术研究等低量用途；同时禁止营销名单、定向广告、系统性抓取、规避速率限制以及把名录包装成未经许可的数据产品。若用户认为访问被错误限制，还应有复核渠道。

换句话说，草案试图把一个模糊的使用边界变成公开的运营契约。此前围绕 prop-173 的一般讨论，理应关注哪些用途被允许、缓存何时变成汇编、自动限制如何接受复核。本文关注另一个更窄的问题：契约会变，旧响应却可能一直存在。

政策有版本，响应只有地址

草案第八部分要求在交付数据时展示提示。WHOIS 响应会写明 APNIC 名录数据受政策约束，查询或使用服务即表示同意条款。RDAP 响应会有标识政策的 notice、关系为 terms-of-service 的链接、知识产权提示和当前政策网址。网页入口则在提交查询和使用结果的时点展示相同约束。

草案还作出两组值得肯定的安排。第一，提示所用的 HTTPS 地址应当稳定、持续维护，而且不经过重定向。第二，中央政策要有版本号、生效日期、修订历史和旧版本档案；修订应提前合理公开通知，实质性放宽再利用或削弱保护的变化，要回到社区协商程序。

这些并非装饰。稳定网址降低链接失效风险，中央文档避免多个协议各自复制一套长条款，旧版档案让规则演变可见，提前通知则减少突袭式变更。响应也不必因塞入整份政策而变得臃肿。任何改进都应保留这些优点。

可问题恰好出在两组安排之间。对响应的要求写的是“当前政策网址”，并没有把适用政策标识、版本号、生效日期或文档摘要列入返回字段。星期一保存的 JSON，星期五仍会指向同一个地址；如果地址内容已经换成新版，旧响应看起来像是在指向星期五的契约。

旧版档案可以补救一部分。如果客户端另存了可信查询时间，而档案准确标明每一版从何时起效，事后就能推回可能适用的版本。HTTP 记录、客户端日志或抓包也可能提供证据。但这些时间来自响应之外。响应自身没有携带把“这份结果”连接到“那份条款”的键。

一份实时 RDAP 样本把差别照了出来

本次冻结的 1.1.1.1 APNIC RDAP 响应已经包含“Terms and Conditions”提示，并附有关系为 terms-of-service 的链接；同一响应还包含数据来源和错误报告提示。它没有政策版本、政策生效日期或条款文档摘要。

这不是 prop-173 已实施的证据。一个样本也不能代表 APNIC 全部 RDAP 节点，更不能代替 WHOIS、网页和其他 API 的检查。它只证明一种现实结构：响应完全可以给出条款目的地，却不说明目的地在查询时的具体版本。

RFC 9083正好说明了这种结构。顶层 notices 可以描述整个服务或整份响应，description 是必需项，links 则可以附带。标准因此给了 APNIC 放置条款链接的空间，也允许它附加一个轻量版本凭据；但标准不会自动生成 APNIC 自己的政策版本字段。协议合规与制度可追溯性不是同一个控制。

不要把三种问题混成一个

APNIC 批量 Whois 协议限制了特定范围以外的复制、储存、传输和批量转交。它说明查询结束后，数据使用规则仍可能继续发生作用；也恰恰说明普通查询需要与批量获取分开说明。

响应级版本凭据并不回答每个字段的权利来自哪里。成员提供的联系人、注册机构生成的结构、别处镜像的内容和客观事实，可能有不同来源。要解决那类问题，需要字段级的来源或权利说明。版本凭据只回答更小的一问：服务在交付这份响应时，援引的是哪一份文字？

APNIC 隐私声明把 Whois 与 RDAP 放在登记和联系信息的处理背景下。标明条款版本不会自动让任何数据使用合法，也不会证明某项限制有效。它的价值只是防止日后拿另一版文字来解释当年的响应。

同样，版本凭据不裁决争议。即便知道确切文本，仍要分别判断 APNIC 有无权力设定某条规则、用语如何解释、用户做了什么、采取何种措施才合比例。凭据只是让讨论从同一份材料出发。

提案阶段正是补上连接的时机

APNIC 政策发展流程以公开讨论和共识为核心。邮件列表上的第一版不是终点，而是接受检验的起点。给 WHOIS 注释和 RDAP notice 增加几个版本字段，不需要推翻草案，也不影响它把普通查询与批量访问分开的主要设计。

证据边界必须保持克制。本次材料没有出现用户被错误版本约束的案例，没有隐藏修订、查询中断、业务损失、路由事故或司法结论。APNIC 也可能有严密的内部发布记录，足以从服务器日志还原适用版本。能够确认的只有一点：prop-173 第一版没有要求这项证明随响应一起返回。

资料来源

本文使用 APNIC 的 prop-173 状态页、第一版提案、批量 Whois 协议、实时 RDAP 样本、隐私声明和政策发展流程，并参照 RFC 9083。这些材料支持草案字段和样本结构，不支持把尚未实施的提案写成一场已经发生的争议。