Summary

  • draft-sparysh-pala-audit-00 was announced on 3 September 2026. Datatracker classifies it as an active individual Internet-Draft with no IETF endorsement or formal standing, no RFC stream and no Responsible Area Director.
  • The draft presents PALA-1 as an existing audit-record wire format frozen at version 1.0. The Palimpsests project made that local freeze on 9 August, before the IETF posting.
  • The draft reports five implementations, but distinguishes the authors’ reference implementation from four text-based reproductions and says those four used project-supplied vectors, not independent vectors.
  • A later run against the v1.0 tag found ambiguities and a span-pairing gap. The draft says the specification changed after the freeze while the stated disposition kept the wire and vectors intact.
  • A thin freeze-and-change receipt should name the frozen object, project authority, IETF process state, review issue, change class, decision maker and compatibility consequence.

One document, two clocks

The IETF announcement introduced PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments on 3 September. Its Datatracker page supplies the essential institutional qualifier: this is an active individual Internet-Draft. Anyone may submit one. The page says it is not endorsed by the IETF and has no formal standing in the standards process. At the reporting cutoff, no RFC stream or Responsible Area Director was recorded, and the IESG state was simply “I-D Exists.”

The document header says its intended status is Informational, while the Datatracker summary field displayed no intended RFC status. Neither observation is an approval. The RFC Editor’s process guide explains that an I-D is a working document, not an RFC, and that posting one does not mean it has been approved or will become an RFC. A working group may later consider and adopt an individual proposal; adoption itself is only one stage before further review and revision.

PALA-1’s other clock had already stopped. On 9 August, Palimpsests commit 50b47edb1ed8 changed the project specification from Draft to “Frozen — v1.0.” The commit defines the promise tightly: the wire no longer changes; a wire change requires a new format_version; profiles may keep allocating additively in their own namespaces. The September Internet-Draft repeats the posture. It says version 1.0 is frozen, presents an existing wire format and does not revise one.

That sequence is not a contradiction. A project may stabilize an artefact for its users before offering it to a standards community. The mistake would be to use one clock as evidence for the other. The project freeze does not show IETF consensus. The absence of IETF adoption does not invalidate a compatibility promise the project made to its implementers.

The freeze was earned with running code

The local exit test is more substantial than a label in a README. The draft’s Implementation Status section reports five implementations: the authors’ reference implementation; a co-maintainer implementation produced under a stated contamination boundary; and three implementations written by people external to the project at the time of their runs, one of whom later became a maintainer.

The wording is commendably exact. The latter four are described as implementations written from the specification text and checked against published, author-supplied test vectors, without access to a prior implementation. The draft explicitly says these are not independent implementations with independent vectors. It reports blind reproductions, defects, adversarial inputs and limitations rather than compressing them into a marketing count.

This is the right direction for running-code primacy. The aim is not to let code overrule every objection. It is to make ambiguity expensive to hide. A parser that produces a different chain head, treats a missing genesis differently or cannot reconstruct a Merkle root exposes a concrete disagreement. The project verification record gives reviewers an inspectable starting point rather than a promise that the prose must be clear because its authors say so.

RFC 7942 gives this kind of material a bounded role. An Implementation Status section can tell reviewers about maturity, coverage, version compatibility, licensing, implementation experience and interoperability reports. The information may help a working group decide how to treat a draft. It is time-dependent, normally removed before RFC publication and does not imply IETF endorsement. Running code strengthens the evidence surface; it does not acquire decision authority.

A post-freeze finding reveals the missing field

The most useful passage is not the success count. It is the account of the fifth run. The draft says an external-at-the-time implementer tested tag pala1-v1.0, passed the listed vector and demonstration checks, constructed additional adversarial cases and logged eight ambiguities plus a span-pairing gap.

The specification says a crash should leave a visibly unclosed span, yet the tester found that no pairing check made that visibility a defined outcome. The disposition did not declare an incomplete trail false. It made the condition an advisory finding. The draft calls this the run that changed the specification after the freeze, and says the finding, reasoning and resolution are public.

Nothing in that account establishes a wire change. On the contrary, the project’s freeze rule and history distinguish textual or interpretive repair from changed fields or vectors. That distinction is precisely why “frozen” needs an object. Bytes can remain stable while an interpretation becomes more explicit. A verifier’s required verdict can remain stable while an advisory diagnostic is added. A profile can evolve while the envelope survives. Those outcomes impose different costs on old readers and writers.

Without a disposition record, two opposite errors become easy. One reader sees any post-freeze edit and concludes that v1.0 was not really frozen. Another sees unchanged bytes and concludes that no normative understanding changed. The public evidence supports neither shortcut. It supports a more useful question: what changed, who classified it, and what must an existing implementation do?

“Frozen” covers several different surfaces

The project specification describes a 156-byte fixed header, TLV extensions, record types and a hash chain. The I-D’s forward-compatibility rule requires a verifier to keep chain-checking unknown versions, record types and TLVs, report them as uninterpretable and not reject the chain merely because they are unknown.

It also identifies a parsing spine that remains at fixed offsets across future versions: magic, format version, header length, record type, sequence, boot ID, previous hash, body length and body digest. Freezing that spine serves a ten-year reader differently from freezing every meaning forever. A future reader can still find the next record and validate the chain even when it cannot understand every body.

Profiles sit at another layer. They define event payloads, aggregate quantities, Merkle leaf sources and origin-role vocabulary. One chain follows one profile, identified in deployment documentation. The core can therefore remain stable while profiles make local domain choices. That is a useful example of minimum initial specification: keep common only what cross-version verification requires, and let future domain decisions remain closer to their implementers.

The format is similarly careful about evidence. It separates internal consistency from completeness against an outside anchor and existence against an outside witness. It says a coherent chain does not prove that its recorder told the truth. These boundaries do not weaken the format. They show that a thin technical invariant works best when it does not claim authority over questions it cannot answer.

The minimum freeze-and-change receipt

PALA-1 does not need a constitution around every commit. It needs a small public join between the compatibility promise and any later review trail.

For each freeze, the receipt should record the exact specification commit and tag, test-vector hashes, freeze actor, date, exit test and unresolved findings. It should name the scope: wire bytes, fixed parsing spine, normative semantics, profiles, implementation guidance or test artefacts. “Version 1.0 frozen” is a summary, not a sufficient data model.

For each later issue, it should record a stable issue ID, the exact revision reviewed, the affected section and a change class: editorial, interpretive, semantic, profile, additive extension, test-vector repair or wire-incompatible. The disposition should name the deciding project or IETF role, its rationale, and one of a small set of outcomes: no change, clarification, advisory, profile revision, extension, compatibility note, new version or deferral.

The compatibility effect belongs beside the decision. Can a v1 reader still find record boundaries? Can it verify the chain? Will it report an unknown record instead of rejecting it? Does a v1 writer remain conformant? Must a profile version change? Which implementation first covers the disposition? A later correction should append history rather than rewrite the original receipt.

Finally, institutional state must remain a separate field set: individual I-D, venue discussion, working-group adoption, consensus, IESG approval and RFC publication are independently nullable. A project maintainer can own the local freeze without speaking for the IETF. A working group can review the proposal without owning the project’s installed base. An implementer can support, reject or fork v1 without pretending that voluntary adoption is institutional approval.

Keep both forms of restraint

RFC 2026 places prior implementation and testing beside technical excellence, clear documentation, openness, fairness and timeliness. It expects specifications to be discussed, reviewed and revised, and it treats multiple implementations as evidence to be evaluated, not a shortcut around the process.

PALA-1’s chronology therefore offers a constructive governance test. The project exercised restraint by narrowing its compatibility promise to a wire format and exposing test evidence. The IETF process exercises a different restraint by refusing to turn an individual posting into endorsement. A useful change receipt lets both survive contact with later findings.

Heng Lu’s running-code and minimum-specification frame sharpens the division. Common rules should be no thicker than interoperability requires. Implementation should test claims against reality. Future choices that do not break the common layer should remain local. Adoption should remain voluntary until an authorized body takes a distinct decision.

The next version of PALA-1 may change nothing. Review may validate the existing choice, propose a clarification, expose a profile problem or demand a new wire version. None of those outcomes can be inferred today. What can be required today is simpler: do not let one word—frozen—stand in for the identity of the frozen artifact, compatibility, authorship and institutional authority all at once.

Sources

  1. IETF Internet-Draft announcement
  2. IETF Datatracker: PALA-1 record
  3. IETF Datatracker: PALA-1 history
  4. IETF archive: draft-sparysh-pala-audit-00
  5. Palimpsests: PALA-1 project specification
  6. Palimpsests commit 50b47edb1ed8: freeze PALA-1 at v1.0
  7. Palimpsests: independent-verification record
  8. Palimpsests: PALA-1 test vectors
  9. Palimpsests: independent-run archive
  10. RFC 7942: Improving Awareness of Running Code
  11. RFC 2026: The Internet Standards Process
  12. RFC Editor: How RFCs Are Created
  13. Heng Lu: Running-Code Primacy
  14. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption