摘要

  • draft-sparysh-pala-audit-00 于2026年9月3日公告。Datatracker把它列为活跃的个人Internet-Draft：没有IETF背书或正式地位，也没有RFC流和负责的区域主任。
  • 草案把PALA-1描述为已经存在并在1.0版冻结的审计记录线格式。Palimpsests项目在8月9日完成本地冻结，早于IETF投稿。
  • 草案报告五份实现，但没有把它们混成一个数字：一份是作者参考实现，其余四份按规范文本复现，并使用项目提供的测试向量，而不是独立向量。
  • 第五次运行在v1.0标签之后发现歧义和span配对缺口。草案称规范在冻结后发生了变更，但所述处置没有改动线格式与向量。
  • 精简的“冻结—变更处置凭证”应分别记录冻结对象、项目决定者、IETF进程状态、意见、变更类型、处置理由和兼容后果。

同一份文本上有两只钟

IETF公告在9月3日发布了 PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments。它的Datatracker页面先划清了机构边界：这是活跃的个人Internet-Draft，任何人都可以提交；它不代表IETF背书，在标准流程中没有正式地位。截稿时，页面没有记录RFC流或Responsible AD，IESG状态只是“I-D Exists”。

文档页眉写着预期状态为Informational，Datatracker汇总字段却显示没有预期RFC状态。两者都不等于批准。RFC Editor对流程的说明指出，Internet-Draft是工作文件，不是RFC；发布草案不表示它已获批准或最终会成为RFC。工作组以后可以考虑并采纳个人草案，但采纳也只是后续讨论、修订和处理异议之前的一个阶段。

项目自己的时钟则在更早时候停住。8月9日，Palimpsests的50b47edb1ed8提交把规范从Draft改成“Frozen — v1.0”。提交说明把承诺限定在线格式：字段、偏移和线规则不再改变；若必须改线，就使用新的format_version；profile仍可在各自命名空间中增量扩展。9月的Internet-Draft沿用了这个立场，明确说它呈现现有线格式，而不是借投稿来重写格式。

这不是逻辑矛盾。项目完全可以在交给标准社区讨论前，为自己的用户稳定一种格式。需要防止的是两只钟互相冒充：项目冻结不证明IETF共识；IETF尚未采纳，也不否定项目对既有实现者作出的本地兼容承诺。

冻结不是靠口号完成的

PALA-1的本地退出测试比一个版本标签更有信息量。草案的Implementation Status章节列出五份实现：作者的参考实现；一份在声明隔离边界下完成的共同维护者实现；以及三份由当时仍在项目之外的人编写的实现，其中一人后来成为维护者。

文本在这里表现出难得的克制。后四份实现按照规范文字工作，用公开的、由项目提供的测试向量核对结果，并且没有接触先前实现。草案同时明确：这是针对作者向量的独立文本实现，不是使用独立向量的独立实现。它还记录盲测、分歧、对抗输入和已知限制，没有把一切压缩成“已有五家支持”的营销数字。

这正是运行代码优先应有的含义。代码不是自动压倒异议的选票，而是让歧义无法舒适地藏在文字里。若两套解析器算出不同链头，若一套把缺失GENESIS归为break而另一套归为violation，若公开材料不足以重算Merkle root，问题就变成可重复的差异。独立验证记录给评审者一个可以检查的起点，而不是要求大家相信作者认为自己写得足够清楚。

RFC 7942给这种证据安排了有限而重要的位置。Internet-Draft可以用Implementation Status说明成熟度、覆盖范围、版本兼容、许可、经验和互操作测试。工作组可以据此判断如何评审，但信息具有时效性，RFC出版前通常会删除，而且列出实现并不意味着IETF背书。运行代码扩大证据面，却不会因此获得决策权。

冻结后的发现揭开真正的治理问题

最值得注意的并不是“5”这个数量，而是第五次运行的处置。草案称，一位当时在项目外部的实现者针对pala1-v1.0标签工作，完成列出的向量和演示检查，又自行构造对抗样本，记录了八项歧义以及一个span配对缺口。

规范原本说，系统崩溃应留下肉眼可见的未闭合span；实现者却发现，没有任何配对检查把这种“可见”定义为验证输出。最后的处理没有把不完整轨迹直接判成伪造，而是把未配对span列为advisory finding。草案自己把它称为“冻结后改变规范”的那次运行，并说发现、理由和处置都留在公开记录中。

现有证据并不显示线格式被改动。相反，项目的冻结规则与记录正是在区分：文字或解释可以修正，字段、偏移与向量不一定变化。这一区分就是治理价值所在。字节保持一致时，解释可能变得更精确；必需的验证结论可以不变，同时增加建议性诊断；profile可以演进，而envelope仍旧兼容。它们对旧reader和旧writer的影响完全不同。

若没有处置凭证，两个相反的误判都很容易发生。一方看到冻结后还有修改，就说1.0根本没冻结；另一方看到向量没变，就说语义理解从未发生变化。公开材料不支持任何一种捷径。它支持一个更可操作的问题：到底改了什么、谁作出分类、现有实现需要做什么？

“冻结”至少指向四个对象

项目规范定义156字节固定头、TLV扩展、记录类型和哈希链。遇到未知版本、类型或TLV时，验证器仍要验链并报告无法解释，不能因此拒绝整条链。

草案还列出跨未来版本保持固定偏移的一组解析骨架：magic、format version、header length、record type、sequence、boot ID、previous hash、body length和body digest。冻结这组骨架，是让十年后的reader仍能找到下一条记录并验链；它并不等同于把所有业务含义永久冻结。

Profile又是另一层。事件正文、聚合量、Merkle叶子来源和ORIGIN_ROLE词表都由profile定义。一条链跟随一个profile，具体身份由部署文档说明。这样，核心可以保持稳定，本地领域仍有未来选择空间。这正符合“最小初始规范”：只把跨版本互操作真正需要的部分做成共同层，其余决定尽量留给实施者。

PALA-1还区分内部一致性、对anchor的完整性和对witness的时间存在性，并承认自洽链不能证明记录者诚实。薄规范只对机制能回答的问题负责。

一张够小的冻结—变更凭证

PALA-1不需要在每个提交周围建立一套宪法。它只需要在兼容承诺与后续评审之间放置一个公开连接点。

每次冻结应记录精确的规范提交、标签和向量哈希，冻结者、时间、退出测试以及当时仍未解决的问题。范围必须单列：是线字节、固定解析骨架、规范语义、profile、实现指导，还是测试材料。v1.0 frozen只能做摘要，不能代替这些字段。

后续每项意见应有稳定编号、被评审的精确版本、相关章节和变更类型：纯编辑、解释澄清、语义规则、profile、增量扩展、测试向量修复或不兼容线改动。处置还要写明由哪个项目角色或IETF角色决定、理由是什么，以及结论是无修改、澄清、advisory、profile更新、扩展、兼容说明、新版本还是延期。

兼容影响应与决定放在一起：v1 reader还能否找到记录边界、还能否验链、会把未知记录报告为不可解释还是直接失败；v1 writer是否仍合规；profile版本是否需要变化；哪份实现首先覆盖该处置。以后若更正，追加历史，不能静默覆盖原来的判断。

最后，机构状态必须单独保存。个人I-D、公开讨论、工作组采纳、共识、IESG批准和RFC出版都应是可独立为空的状态。项目维护者可以负责本地冻结，却不能替IETF发言；工作组可以评审提案，却不自动接管项目的安装基础；实现者可以支持、拒绝或fork v1，而不必把自愿采用说成机构批准。

让两种克制同时存在

RFC 2026把先行实现与测试放在技术卓越、清晰文档、开放、公平和及时性旁边。规范需要反复讨论、评审与修订，多份实现是应被判断的证据，不是绕过流程的通行证。

因此，PALA-1提供的是一场建设性的治理测试。项目的克制，在于把承诺缩到线格式并公开测试证据；IETF流程的克制，在于不把个人投稿自动抬升为背书。一张清楚的变更凭证，可以让两者面对后续发现时都不失真。

Heng Lu的框架给出同一条边界：共同规则不应厚于互操作所需，代码检验主张，不破坏共同层的未来选择留在本地。下一版可能维持现状，也可能要求澄清、profile更新或新线版本；今天不能预言。能够确定的是，frozen不能同时代替对象身份、兼容性、作者权和IETF权力。

来源

  1. IETF Internet-Draft公告
  2. IETF Datatracker：PALA-1记录
  3. IETF Datatracker：PALA-1历史
  4. IETF归档：draft-sparysh-pala-audit-00
  5. Palimpsests：PALA-1项目规范
  6. Palimpsests提交50b47edb1ed8：冻结PALA-1 v1.0
  7. Palimpsests：独立验证记录
  8. Palimpsests：PALA-1测试向量
  9. Palimpsests：独立运行归档
  10. RFC 7942：让运行代码进入评审
  11. RFC 2026：Internet标准流程
  12. RFC Editor：RFC如何产生
  13. Heng Lu：Running-Code Primacy
  14. Heng Lu：Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption