Zusammenfassung

  • Am 3. September 2026 stellte die IESG fest, dass Revision 12 von Safe-IOC nicht mit IETF-Arbeiten kollidiert. Das war keine technische Billigung, kein IETF-Konsens und keine Standards-Track-Zulassung.
  • Revision 13 und 14 folgten. Öffentliche Diffs spiegeln mehrere Ballot-Hinweise wider; die Historie zeigt ISE-, IANA- und RFC-Produktionsschritte. Ein vollständiger öffentlicher Nachweis über Annahme, Ablehnung oder Teilannahme jedes Kommentars fehlt.
  • Ein Versions- und Kommentarentscheidungsbeleg sollte Hash und Datum der geprüften Fassung, RFC-5742-Antwort, stabile Kommentar-IDs, ISE-Gründe, exakte Diffs, IANA/RPC-Zustände und später RFC-Nummer und Stream-Boilerplate verbinden.

Das Urteil gehört zu Revision 12

Die IESG-Mitteilung nennt draft-grimminck-safe-ioc-sharing-12. Die IESG hatte kein Problem mit einer Veröffentlichung als Informational RFC und sah keinen Konflikt mit IETF-Arbeit. Separat bat sie den Independent Submissions Editor, Kommentare in Ballot und Datatracker-Historie zu prüfen und über ihre Aufnahme zu entscheiden.

Damit existieren mehrere Zustände. Die Konfliktprüfung für Revision 12 war abgeschlossen. Technische Kommentare blieben beim ISE. Der Independent Stream durfte fortfahren. Veröffentlicht war noch kein RFC.

Der aktuelle Datatracker-Eintrag zeigt Revision 14, weiterhin als active individual Internet-Draft im Independent Submission Stream mit vorgesehenem Status Informational. Die Dokumentidentität blieb, Bytes und Produktionslage änderten sich.

RFC 5742 begrenzt die Rolle der IESG

RFC 5742 kennt fünf Konfliktantworten. Verwendet wurde die erste und engste: kein Konflikt mit IETF-Arbeit. Derselbe RFC erklärt, dass Nicht-IETF-Streams gewöhnlich weder IETF-Konsens noch IESG-Genehmigung anstreben. Nach einem konfliktfreien Ergebnis bewertet weiterhin der RFC Editor technische Qualität und mögliche Schäden für das Internet.

Diese Trennung verhindert, dass die IESG eine Grenzprüfung zur Vollprüfung ausweitet oder der ISE das konfliktfreie Ergebnis als Ersatz für eigenes Urteil nutzt. „No problem with publication“ beseitigt diesen Hinderungsgrund; es empfiehlt die Spezifikation nicht im Namen der IETF.

Auch die Ballot-Frage war eng: Ist die vorgeschlagene Konfliktantwort richtig? Zum Stichtag standen zwei Yes und acht No Objection. Das sind Positionen zur institutionellen Antwort, keine zehn technischen Zustimmungen zu jeder Regel und Sicherheitsbehauptung.

Sichtbare Änderungen ohne vollständige Zuordnung

Mohamed Boucadair unterstützte die Antwort und schlug vier Anpassungen vor: RFC 9424 als IoC-Hintergrund; Verzicht auf „safe“, wenn nur Risiko reduziert wird; klare Unterscheidung von Präfixen und Adressen; sowie RFC-6052-Fälle für eingebettetes IPv4 in IPv6. Éric Vyncke hinterließ einen kurzen Hinweis zum Umfang des IPv6-Inhalts.

Revision 13 erschien nach der Mitteilung. Historie und Diff 12–14 zeigen deutliche Entsprechungen: Aus “a safe obfuscation format” wird “an obfuscation format”; RFC 9424 kommt hinzu; CIDR-Text spricht von Präfixen; RFC 6052 und zwei Testfälle werden ergänzt; Boucadair erscheint in den Danksagungen.

Das belegt, dass spätere Fassungen die Hinweise widerspiegeln. Es belegt keine formale Einzelfallentscheidung. Der Diff verrät nicht, ob der ISE einen Punkt wörtlich akzeptierte, mit anderer Review-Arbeit verband oder dieselbe Änderung aus anderem Grund vornahm.

Revision 14 ergänzt „defanging“, präzisiert Host-Grammatik und RFC-1035-Verweise, macht aus zwei großgeschriebenen SHOULD gewöhnliche Empfehlungen und fügt eine Warnung vor Token-Mehrdeutigkeit in Path, Query oder Fragment hinzu. Eine öffentliche Tabelle, die all diese Änderungen mit stabilen IDs und Accept/Reject/Partial-Entscheidungen verbindet, existiert nicht.

Produktionsarbeit ist noch keine Veröffentlichung

Am 9. September wurde Revision 14 hochgeladen und vom ISE an den RFC Editor gesendet. IANA wechselte zu In Progress und am 16. September zu No IANA Actions. Die RFC-Produktion war kurz wegen Author Input Required blockiert und lief danach weiter. Die RPC-Historie wechselte später von Referenzprüfung und Formatierung zum Warten auf Editor-Zuweisung.

Das offizielle Queue-XML führt Revision 14 weiterhin im ISE Stream, eingegangen am 9. September, mit ref_checker. Datatracker und Queue zeigen verschiedene Sichten auf die Arbeit; keine bedeutet pauschal „genehmigt“. Eine endgültige RFC-Nummer fehlt.

Der Ablauf für Independent Submissions trennt wiederholte Reviews, erste Publikationsentscheidung, Übergabe an den RPC, AUTH48 und Veröffentlichung. Bis zur Freigabe als RFC kann der ISE noch von der Publikation absehen. Die Queue beweist Obhut und Bearbeitung, nicht das fertige öffentliche Werk.

Der erforderliche Übergabebeleg

Die erste Zeile bindet exakten Hash und Zeitpunkt von Revision 12 an die RFC-5742-Antwort. Jeder Kommentar erhält stabile ID, Autor, Texthash und Fundstelle. Der ISE dokumentiert accepted, rejected oder partially accepted samt Grund. Bei Annahme verweist der Eintrag auf die erste umsetzende Revision und den genauen Diff-Hunk.

Die Kette erfasst anschließend IANA-Ergebnis, Gründe und Aufhebung von RPC-Blocks, Verantwortliche, RFC-Nummer, Stream-Boilerplate sowie spätere Errata oder Nachfolger. Ein beratender Hinweis bleibt beratend; Änderungen aus anderer Review-Arbeit werden nicht rückwirkend dem Ballot zugerechnet.

Auch Sicherheitsversprechen bleiben so begrenzt. Eine reversible Textkonvention kann versehentliche Aktivierung reduzieren. Sie prüft nicht, ob ein Indikator bösartig, aktuell oder richtig attribuiert ist. Dokument-Provenienz und IOC-Provenienz sind getrennte Nachweise.

Quellen