Zusammenfassung

  • Am 29. August waren zwei endungslose Links zu den Protokollen von AVTCORE und MMUSIC beim IETF 84 nicht nutzbar; in einer per rsync bezogenen Kopie lagen passende Dateien dennoch vor.
  • IETF-Mitarbeiter erweiterten die vom Webserver geprüften Endungen um PDF, HTM und weitere tatsächlich vorhandene Varianten. Eine begrenzte Kontrolle am 6. September erhielt auf beiden ursprünglichen Routen HTTP 200.
  • Gespeicherte Existenz, öffentliche Erreichbarkeit, die Identität des ausgelieferten Objekts und die Integrität seiner Bytes sind vier unterschiedliche Zustände.
  • Ein maschinenlesbares Manifest sollte jede Sitzungsunterlage mit stabiler Kennung, konkretem Pfad, Medientyp, Größe, Hash, Version, Korrektur- und Nachfolgestatus sowie dem letzten Prüftermin verbinden.
  • Das Manifest ersetzt weder das Protokoll noch die IETF-Verfahren. Es macht lediglich die Auswahl des Servers und die Versionsgeschichte überprüfbar.

Der Fund im Spiegel widerlegt nicht den Fehler im Browser

Jörg Ott berichtete am 29. August, dass sich aus den IETF-84-Unterlagen die Protokolle von AVTCORE und MMUSIC nicht abrufen ließen. Stichproben bei anderen Gruppen funktionierten. In seiner ersten Meldung regte er automatische Linkprüfungen an und erwähnte eine Cloudflare-Antwort 1015, die ihm bei der Untersuchung über eine schlechte entfernte Mobilfunkverbindung begegnete.

Das war ein nachvollziehbarer Zugangsfehler, aber kein Nachweis für Löschung oder Manipulation. Carsten Bormann betrachtete eine andere Oberfläche. In einer lokalen rsync-Kopie der Proceedings fand er Dateien für beide Gruppen; den gesamten lokalen Bestand bezifferte er auf 68 GB. Diese Momentaufnahme sagt nichts über die Vollständigkeit aller Jahrgänge oder eine durchgehende Byte-Gleichheit. Für die beiden Fälle trennt sie jedoch klar das Vorhandensein vom öffentlichen Pfad.

Ott brachte das Verhalten anschließend mit PDF- und HTM-Endungen in Verbindung. Am 2. September folgte die betriebliche Erklärung: Alte Sitzungsseiten verlinkten Protokollnamen ohne Dateiendung, während der Server nur eine begrenzte Kandidatenliste ausprobierte. IETF-Mitarbeiter erweiterten diese Liste um .pdf, .htm und weitere Varianten aus den Bestandsdaten. Die gemeldeten Beispiele und mehrere ähnliche Fälle sollten damit wieder funktionieren.

Zur Ratenbegrenzung hieß es in derselben Antwort, sie sei relativ hoch eingestellt und durch gewöhnliches Browsen schwer zu erreichen. Bei einem erneuten Fall solle die Cloudflare Ray ID mitgeteilt werden. Das widerlegt Otts beobachtete 1015-Antwort nicht; ebenso wenig belegt ein einzelner Vorfall eine allgemeine Nichtverfügbarkeit. Namensauflösung und Zugriffsbeschränkung müssen getrennte Fehlerklassen bleiben.

Auch die falsche Datei kann erfolgreich antworten

Bei einer zurückhaltenden Prüfung am 6. September lieferte die endungslose AVTCORE-Route ein 242.140 Byte großes PDF mit einem Last-Modified-Wert von 2012. Der beobachtete SHA-256 lautete 937e224285a7eae6bf1cbeb9106e5eb0bf4df7b34bf02a10587f6da9ef4e49e1. Die MMUSIC-Route gab HTML zurück, ebenfalls mit einem Änderungswert von 2012 und dem beobachteten SHA-256 88a6f5fd2d5459bfa1c66dc7d24b54e441a4e05507e009adf99409486c19a214.

Diese Hashes dokumentieren einen Abruf zu einem bestimmten Zeitpunkt. Sie erklären sich nicht selbst zur ewigen kanonischen Version. Direkte Pfade mit avtcore.html und mmusic.html antworteten ebenfalls, lieferten aber andere Bytes und Gruppenzusammenfassungen mit einem Datum von 2021 — nicht die Sitzungsprotokolle. Eine vermeintlich naheliegende .html-Ergänzung kann somit zu einem echten, aber falschen Dokument führen.

Der Index der IETF-84-Unterlagen ist für Menschen gebaut. Eine flexible Endungsauflösung hält alte Links trotz historisch uneinheitlicher Namen nutzbar. Sie verschmilzt jedoch vier Fragen, die unterschiedliche Belege brauchen:

  1. Existenz: Enthält ein Speicher oder Spiegel eine zur Sitzung gehörende Unterlage?
  2. Erreichbarkeit: Kann eine öffentliche Anfrage derzeit etwas abrufen?
  3. Identität: Ist die Antwort das deklarierte Protokoll und nicht eine Gruppenseite oder ein zufälliger Kandidat?
  4. Integrität: Stimmen die Bytes mit der für einen bestimmten Zeitpunkt ausgewiesenen Version überein?

Die Änderung verbesserte unmittelbar die Erreichbarkeit. Bormanns Kopie belegte begrenzt die Existenz. Medientyp, Länge und Hash geben Ansatzpunkte für Identität und Integrität. Keine Kombination dieser Merkmale bescheinigt automatisch Vollständigkeit, inhaltliche Richtigkeit oder institutionelle Billigung.

Ein Protokoll durchläuft mehr Zustände als vorhanden und fehlend

RFC 2418 verlangt einen Bericht für jede Arbeitsgruppensitzung, überträgt dem Vorsitz die Verantwortung, die Erstellung des Protokolls sicherzustellen, und zählt öffentliche Mailinglistenarchive zum Arbeitsgedächtnis. Wichtige Entscheidungen und ihre Geschichte sollen zusammengefasst und archiviert werden. Ein nicht auffindbarer Zugang beeinträchtigt deshalb mehr als die Pflege einer alten Website.

Auch die aktuelle Anleitung für Sitzungsunterlagen macht die Einreichung von Protokollen verpflichtend, nennt zulässige Formate und unterscheidet Abgabe- und Korrekturfrist. Eine Erinnerung des Sekretariats zu IETF 126 führte am 13. August Sitzungen auf, deren Protokolle vor dem Abgabetermin noch fehlten, und nannte den 8. September als Korrekturschluss. Daraus folgt kein endgültiger Fehlbestand. Es zeigt vielmehr die Zustandsfolge: noch nicht eingereicht, eingegangen, veröffentlicht, korrigiert, ersetzt und derzeit erreichbar.

Ein striktes Verzeichnis hinter einer großzügigen URL

Das Integritätsmanifest sollte für jede Unterlage Sitzungsnummer, Gruppe oder Session, Materialart und eine stabile logische Kennung ausweisen. Diese Identität wird mit dem konkreten Objektpfad, MIME-Typ, der Bytezahl und einem kryptografischen Hash verbunden.

Hinzu kommen Empfangs- und Veröffentlichungszeit, Version, aktueller, korrigierter oder abgelöster Status, Verweis auf einen Nachfolger, Zeitpunkt der letzten erfolgreichen öffentlichen Prüfung und das Reparatur- oder Migrationsereignis, das den Zugriff verändert hat. Herkunft lässt sich, soweit sicher, über eine Rolle angeben, ohne private Korrespondenz, persönliche Netzdaten, Zugangsdaten oder Schutzdetails offenzulegen.

Eine Korrektur erzeugt eine neue Version und eine explizite Nachfolgebeziehung. Sie lässt nicht heimlich neue Bytes unter einem alten Hash auftreten. Der menschenfreundliche Link darf weiterhin zur aktuellen Fassung führen; für Forschung und Zitation bleibt jede konkrete Fassung eindeutig benennbar.

Das Manifest ist kein zweites Protokoll. Es bewertet nicht, ob die Mitschrift die Sitzung richtig wiedergibt, und verleiht keine Autorität. Es macht begrenzte Betriebsbehauptungen prüfbar: Unterlage fehlt, Objekt liegt vor, Link löst nicht auf, falscher Kandidat, falsches Format, Zugriffsbeschränkung, Prüfsummenabweichung, abgelöste Version oder unbekannte Ursache.

Öffentliche Kontrollen sollten langsam und verteilt erfolgen, damit die Prüfung nicht selbst zur Last wird. Grün bedeutet nur, dass das deklarierte Objekt zu einem protokollierten Zeitpunkt abgerufen wurde und Format, Größe sowie Hash übereinstimmten. Gerade diese enge Aussage ist belastbar.

Quellen

  1. Jörg Otts Meldung zu den IETF-84-Protokollen
  2. Carsten Bormann zur rsync-Kopie
  3. Nachtrag zu PDF- und HTM-Endungen
  4. Erklärung und Reparatur durch IETF-Mitarbeiter
  5. Erinnerung an IETF-126-Protokolle
  6. IETF-Leitfaden für Sitzungsunterlagen
  7. RFC 2418
  8. IETF-84-Unterlagen
  9. AVTCORE-Protokollroute
  10. MMUSIC-Protokollroute
  11. Lu Heng über den Vorrang lauffähigen Codes