Zusammenfassung

  • draft-sparysh-pala-audit-00 wurde am 3. September 2026 angekündigt. Datatracker führt ihn als aktiven individuellen Internet-Draft ohne IETF-Billigung oder formellen Status, ohne RFC-Stream und ohne zuständigen Area Director.
  • Der Text beschreibt PALA-1 als bestehendes Audit-Wire-Format, das in Version 1.0 eingefroren ist. Das Palimpsests-Projekt vollzog diesen lokalen Freeze bereits am 9. August.
  • Der Draft nennt fünf Implementierungen, trennt aber die Referenz der Autoren von vier Umsetzungen nach dem Text, die mit projektseitigen Vektoren geprüft wurden.
  • Ein späterer Lauf gegen den v1.0-Tag fand Unklarheiten und eine Lücke bei der Zuordnung von Spans. Der Draft spricht von einer Spezifikationsänderung nach dem Freeze, ohne eine Änderung von Wire oder Vektoren zu behaupten.
  • Ein schlanker Freeze-und-Change-Beleg sollte Objekt, Projektrolle, IETF-Zustand, Befund, Änderungsklasse, Entscheidung und Folgen für bestehende Reader und Writer getrennt ausweisen.

Das Projekt und die IETF starten nicht dieselbe Uhr

Die IETF-Ankündigung erschien am 3. September. Der Datatracker-Eintrag setzt die institutionelle Grenze: Jeder kann einen I-D einreichen; dieser Text ist nicht von der IETF gebilligt und besitzt keinen formellen Rang im Standardsprozess. Zum Stichtag waren weder RFC-Stream noch Responsible AD vermerkt. Der IESG-Status lautete lediglich „I-D Exists“.

Im Dokumentkopf steht als Ziel Informational, während das Zusammenfassungsfeld im Datatracker keinen intended RFC status auswies. Beides ist keine Genehmigung. Der RFC Editor erläutert, dass ein Internet-Draft ein Arbeitsdokument und kein RFC ist. Auch eine mögliche spätere Working-Group-Adoption wäre nur eine Stufe vor weiterer Diskussion und Überarbeitung.

Das Projekt hatte seine eigene Uhr schon angehalten. Mit Commit 50b47edb1ed8 vom 9. August änderte Palimpsests den Status von Draft zu „Frozen — v1.0“. Das Versprechen gilt dem Wire: Eine Änderung daran verlangt ein neues format_version; Profile dürfen in ihren Bereichen additiv wachsen. Der September-Draft stellt das Format entsprechend als bestehend dar und sagt ausdrücklich, dass er es nicht revidiert.

Diese Reihenfolge ist zulässig. Ein Projekt kann seinen Anwendern Stabilität zusagen, bevor es eine breitere Standardisierung anstrebt. Entscheidend ist, die Zustände nicht zu vermengen. Der Freeze bindet die lokale Release-Entscheidung, nicht die IETF. Fehlende IETF-Adoption löscht umgekehrt nicht den Nutzen oder das Versprechen des Projekts.

Implementierungen sind Belege mit Herkunft

Der Implementation-Status-Abschnitt nennt fünf Umsetzungen: die Referenz der Autoren, eine Co-Maintainer-Implementierung unter offengelegter Abgrenzung sowie drei Arbeiten von Personen, die zum Zeitpunkt ihrer Läufe projektfremd waren. Eine wurde später Maintainer.

Die Darstellung ist genauer als eine bloße Zahl. Die vier nichtreferenziellen Implementierungen entstanden aus dem Spezifikationstext ohne Zugriff auf eine frühere Umsetzung und verglichen ihre Ergebnisse mit vom Projekt gelieferten Testvektoren. Der Draft nennt diese Vektoren nicht unabhängig. Eine Textreproduktion, Interoperabilität zwischen Produkten und Produktionsbetrieb bleiben verschiedene Belegarten.

So erhält Running-Code-Primacy ihren richtigen Sinn. Code stimmt nicht ab; er macht Widerspruch messbar. Abweichende Hashes, unterschiedliche Fehlerklassen oder nicht reproduzierbare Merkle-Werte zwingen den Text zur Präzisierung. Das Verifikationsprotokoll zeigt Funde und ihre Bearbeitung, anstatt nur fertige Erfolge aufzuzählen.

RFC 7942 weist Implementation Status genau diese begrenzte Rolle zu. Reifegrad, Abdeckung, Versionskompatibilität, Lizenz und Erfahrungen können Prüfern helfen. Working Groups bestimmen das Gewicht selbst. Die Auflistung ist keine IETF-Billigung und wird wegen ihrer Zeitabhängigkeit üblicherweise vor einer RFC-Veröffentlichung entfernt.

Der Befund nach dem Freeze

Besonders aufschlussreich ist Lauf fünf. Laut I-D arbeitete der damalige externe Implementierer gegen den Tag pala1-v1.0, bestand die veröffentlichten Prüfungen, fügte eigene Angriffsfälle hinzu und dokumentierte acht Mehrdeutigkeiten sowie eine Lücke beim Span-Pairing.

Die Spezifikation verlangte, dass ein Absturz einen sichtbar offenen Span hinterlässt, definierte aber keine einheitliche Paarprüfung. Die Lösung erklärte einen abgebrochenen Trail nicht automatisch für gefälscht. Ein ungepaarter Span wurde als advisory finding ausgegeben. Der I-D bezeichnet diesen Lauf als jenen, der die Spezifikation nach dem Freeze änderte, und verweist auf den öffentlichen Entscheidungsweg.

Das belegt keine Änderung der Wire-Bytes. Es belegt, dass ein Freeze sein Objekt benennen muss. Textklärung, zusätzliche Diagnose, normative Semantik, Profiländerung und verschobener Offset sind nicht dasselbe. Gleiche Vektoren können mit einer präziseren Interpretation einhergehen; dieselbe Absicht kann durch eine Byteänderung alte Parser brechen.

Ohne Dispositionsprotokoll entstehen zwei Kurzschlüsse: Jede spätere Textänderung widerlege den Freeze, oder unveränderte Vektoren bewiesen unveränderte Bedeutung. Für Implementierer zählen stattdessen Gegenstand, Klassifizierer und notwendige Reaktion.

Nur den notwendigen gemeinsamen Kern einfrieren

Die Projektspezifikation definiert einen 156-Byte-Header, TLV-Erweiterungen, Record-Typen und eine Hash-Kette. Bei unbekannter Version, unbekanntem Typ oder TLV soll ein Verifier die Kette weiter prüfen, das Element als nicht interpretierbar melden und nicht allein deshalb alles ablehnen.

Ein Parsing-Rückgrat behält feste Offsets: Magic, Versionsnummer, Längen, Record-Typ, Sequenz, Boot-ID, vorheriger Hash und Body-Digest. Damit findet ein alter Reader auch in künftigen Records die nächste Grenze. Diese mechanische Stabilität friert nicht jede Bedeutung ein.

Profile bestimmen Event-Bodies, Aggregate, Merkle-Quellen und Rollenwortschatz. Die Deployment-Dokumentation weist das verwendete Profil aus. Das ist eine minimale Anfangsspezifikation: gemeinsam bleibt, was Interoperabilität trägt; spätere Fachentscheidungen bleiben lokal.

Auch Evidenz wird nicht zentral zusammengezogen. PALA-1 trennt interne Konsistenz, Vollständigkeit gegenüber einem Anchor und Existenz gegenüber einem Witness. Eine konsistente Kette beweist nicht, dass der Aufzeichner wahrheitsgemäß schrieb. Diese Grenze macht das Format institutionell bescheidener und technisch glaubwürdiger.

Ein kleiner Dispositionsbeleg

Der Freeze-Datensatz sollte Commit, Tag, Vektor-Hashes, entscheidende Rolle, Datum, Exit-Test und offene Punkte enthalten. Das Feld scope unterscheidet Wire-Bytes, Parsing-Rückgrat, normative Semantik, Profil, Implementierungshinweis und Testartefakt.

Jeder spätere Befund erhält stabile ID, geprüfte Revision, Abschnitt und Änderungsklasse: redaktionell, interpretativ, semantisch, Profil, additive Extension, Vektor-Reparatur oder Wire-Inkompatibilität. Die Disposition nennt Projekt- oder IETF-Rolle, Begründung und Ergebnis: keine Änderung, Klarstellung, Hinweis, Profilrevision, Erweiterung, Kompatibilitätsnotiz, neue Version oder Aufschub.

Die Wirkung gehört daneben. Findet ein v1-Reader weiter Record-Grenzen und prüft die Kette? Bleibt ein v1-Writer konform? Braucht das Profil eine neue Fassung? Spätere Korrekturen ergänzen die Historie, statt den früheren Beschluss zu überschreiben.

Institutionelle Zustände bleiben getrennt: individual I-D, benanntes Diskussionsforum, WG adoption, consensus, IESG approval und RFC publication. Maintainer sprechen für ihr Projekt, nicht für die IETF. Eine Working Group prüft einen Text, übernimmt aber nicht automatisch dessen installierte Basis. Betreiber dürfen v1 freiwillig nutzen, ohne einen Standardstatus zu erfinden.

RFC 2026 stellt Implementierung und Tests neben technische Qualität, klare Dokumentation, Offenheit, Fairness und wiederholte Prüfung. Laufender Code ist Teil der Disziplin, keine Abkürzung zur Autorität.

Heng Lus Rahmen ergänzt: Der gemeinsame Teil soll so dünn bleiben, wie Interoperabilität erlaubt; Code prüft Worte an der Realität; nicht brechende Zukunftsentscheidungen bleiben lokal; freiwillige Nutzung ist kein Mandat. PALA-1 kann unverändert bleiben oder nach späterer Prüfung eine Klarstellung, ein Profilupdate oder v2 benötigen. Das ist offen. Nicht offen sollte sein, was das Wort frozen meint und wer darüber sprechen darf.

Quellen

  1. IETF-Ankündigung
  2. Datatracker: PALA-1
  3. Datatracker-Historie
  4. IETF-Archiv: Version 00
  5. PALA-1-Projektspezifikation
  6. Freeze-Commit 50b47edb1ed8
  7. Independent-Verification-Protokoll
  8. PALA-1-Testvektoren
  9. Archiv unabhängiger Läufe
  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