Summary

  • On 3 September 2026, the IESG found no conflict between IETF work and revision 12 of the Safe-IOC Independent Submission. That finding did not approve the draft’s technical content, create IETF consensus or put it on the Standards Track.
  • Revisions 13 and 14 followed. Public diffs show several ballot suggestions reflected in the new text, while Datatracker history shows ISE, IANA and RFC production activity. None of those records, by itself, supplies an item-by-item disposition linking every comment to an attributable decision and exact changed bytes.
  • A version-and-comment-disposition receipt would preserve the reviewed hash, the RFC 5742 response, stable comment identifiers, ISE decisions, implementation diffs, IANA and RPC state, and eventual RFC boilerplate without turning progress through a queue into endorsement or publication.

The decision points to an older object

The IESG announcement is exact about its object. It says the review covered draft-grimminck-safe-ioc-sharing-12, found no conflict with IETF work, and had no problem with publication as an Informational RFC. It then makes a separate request: the Independent Submissions Editor should examine comments in the Datatracker ballot and history and decide whether they merit incorporation.

Those sentences establish different states. A conflict check was complete for revision 12. Technical comments remained for the ISE to judge. The non-IETF publication process could continue. No sentence says that every technical claim had been approved, that every comment had been accepted, or that any RFC had been published.

The current Datatracker record now points to revision 14. It still labels the document an active individual Internet-Draft in the Independent Submission stream with intended status Informational. The identity of the draft survived. The bytes and downstream production state changed.

RFC 5742 deliberately narrows the IESG’s role

RFC 5742 lists five possible conflict-review conclusions. The response used here is the first and narrowest: no conflict between the document and IETF work. The same RFC explains that non-IETF-stream documents generally do not seek IETF consensus or IESG approval, and that after a no-conflict result the RFC Editor remains responsible for judging technical merit and possible harm to the Internet.

This division of labour prevents two opposite errors. The IESG should not silently turn a conflict check into full technical review. The ISE should not treat a no-conflict response as a substitute for editorial and technical judgement. “No problem with publication” means the Independent stream is not blocked on this ground; it does not mean the IETF has endorsed the specification.

The ballot page reinforces that boundary. Its question is whether the proposed conflict-review response is correct. At the reporting cutoff it records two Yes positions and eight No Objection positions. Those positions answer the institutional question on the ballot. They are not ten votes approving each transformation rule, test vector or security claim in the draft.

A visible path from comments to new text

One ballot comment provides a useful audit trail. Mohamed Boucadair agreed with the conflict response and separately suggested four small technical changes: cite RFC 9424 for IoC background; avoid calling the format “safe” when it reduces rather than eliminates risk; distinguish prefixes from addresses; and cover RFC 6052 IPv4-embedded IPv6 forms. Éric Vyncke left a lighter comment about the amount of IPv6 material.

Revision 13 appeared after the announcement. The revision history and the 12-to-14 comparison show a strong visible correspondence. The abstract changes “a safe obfuscation format” to “an obfuscation format”. RFC 9424 is added. CIDR language is recast as prefixes. RFC 6052 and two embedded-IPv4 test cases appear. Boucadair is added to the acknowledgements.

That evidence supports a careful statement: the later text reflects those suggestions. It does not prove a formal disposition for every point. A diff cannot tell the reader whether the ISE accepted an item as written, accepted it for another reason, combined it with other review, or considered a broader issue resolved by a different hunk.

Revision 14 adds another layer. It introduces the familiar term “defanging”, tightens the host grammar and RFC 1035 citations, changes two uppercase requirement words to ordinary lowercase advice, and adds a security paragraph about bracket-token ambiguity inside a Path, Query or Fragment. It also expands the acknowledgements. The public record does not map each of these changes to a stable review item and an attributable accept, reject or partial-accept decision.

Production movement is not publication

The state trail continued on 9 September. Revision 14 was uploaded, and the ISE sent it to the RFC Editor. IANA processing moved into progress and later to “No IANA Actions”. RFC production moved from in progress to blocked for author input, then back to in progress. By 16 September the RPC history showed movement from reference checking and formatting to awaiting editor assignment.

The official RFC Editor queue XML still lists draft-grimminck-safe-ioc-sharing-14 in the ISE stream, received on 9 September, with a reference-checker assignment. The Datatracker and queue describe different projections of production work, so neither should be compressed into a single word such as “approved”. At the cutoff there is no final RFC number.

The Independent Submission process explicitly includes repeated review and document updates, an initial publication decision, handoff to the RFC Production Center, AUTH48 and only then publication. It also says the ISE may decline publication until an RFC is released. A queue entry is therefore evidence of custody and work, not proof of the final public object.

The missing receipt

The durable control is a version-and-comment-disposition receipt. Its first row should bind revision 12 by exact hash and timestamp to the RFC 5742 response. Each comment should then carry a stable identifier, author, text hash and source surface. The ISE’s result should be explicit: accepted, rejected or partially accepted, with reasons. Accepted items should point to the first implementing revision and an exact diff hunk.

The same receipt can continue through IANA and RPC without collapsing their roles. It should record whether IANA found actions, the dates and reasons for RPC blocks and releases, the responsible actor, the final RFC number and stream boilerplate, and any later erratum or replacement. If a public comment is advisory, that should be visible. If a change arose elsewhere, it should not be retroactively attributed to the ballot.

This discipline also protects the specification from exaggerated security claims. A consistent reversible text convention may reduce accidental activation. It does not validate that an indicator is malicious, current, correctly attributed or harmless to process. Provenance for the document and provenance for the threat indicator remain different records.

Sources