要約

  • 2026年9月3日、IESGはSafe-IOC Independent Submission第12版とIETF作業の間に衝突がないと判断した。この判断は技術的な推奨、IETFの合意、標準化トラックの承認ではない。
  • その後に第13版と第14版が出た。公開差分にはballot上の提案を反映したと読める変更があり、DatatrackerにはISE、IANA、RFC制作の進行がある。しかし、各コメントの採否、理由、変更箇所を一対一で示す処理表はない。
  • 版・コメント処理の受領記録には、審査版のハッシュ、RFC 5742応答、コメントの安定ID、ISEの判断、実装差分、IANA/RPC状態、最終RFCのboilerplateを残すべきだ。キュー入りを公開や承認に読み替えてはならない。

結論と対象版がずれた瞬間

IESGの告知は、審査対象をdraft-grimminck-safe-ioc-sharing-12と特定している。IESGはInformational RFCとしての公開に問題はなく、IETF作業との衝突もないとした。一方で、DatatrackerのballotとhistoryにあるコメントをIndependent Submissions Editorが調べ、文書に入れる価値があるかを判断してほしいとも述べた。

ここには別々の状態がある。第12版の衝突審査は終わった。技術コメントの処理はISEに残った。Independent streamは先へ進める。RFCはまだ公開されていない。どれか一つを他の状態の証明に使うことはできない。

現在のDatatrackerは第14版を示し、なおactive individual Internet-Draft、Independent Submission、想定status Informationalと記録している。文書の識別子は続いても、判断対象のバイト列と制作上の位置は変化した。

RFC 5742は技術承認の仕組みではない

RFC 5742は衝突審査の結論を五種類に分ける。今回の応答は最も狭い第一類型、すなわちIETF作業との衝突なしである。同RFCは、非IETF streamの文書について通常はIETF合意やIESG承認を求めず、無衝突の場合も技術的価値とInternetへの害の可能性はRFC Editor側が判断すると説明する。

この分業は双方を制約する。IESGは衝突確認を全面的な技術審査に膨らませない。ISEは無衝突を技術審査の代用品にしない。「公開に問題なし」とは、この理由ではIndependent streamを止めないという意味であり、IETFが仕様を推奨したという意味ではない。

ballotの質問も、提案されたconflict-review responseが正しいかどうかである。締切時点の記録はYesが二名、No Objectionが八名だ。これは制度上の応答へのpositionであり、変換規則、試験ベクトル、安全性の記述を一項ずつ承認した十票ではない。

読める差分と、読めない処理理由

Mohamed Boucadairは衝突応答に賛成したうえで、RFC 9424の参照、「safe」が危険をゼロにするように読める点、addressとprefixの区別、RFC 6052のIPv4埋め込みIPv6例を指摘した。Éric VynckeはIPv6の記述量について短いコメントを残した。

告知後に第13版が提出された。履歴と第12版から第14版の差分を見ると、提案との対応は強い。abstractの “a safe obfuscation format” は “an obfuscation format” になり、RFC 9424が追加され、CIDRの表現はprefixに整理され、RFC 6052と二つの試験例が入り、謝辞にBoucadairが加わった。

しかし、差分が示すのは新旧テキストであって、正式なdispositionではない。ISEが提案どおり採用したのか、別のreviewを理由に同じ変更をしたのか、複数の指摘をまとめたのかは差分だけでは決められない。

第14版ではさらに、一般語の “defanging”、host grammarとRFC 1035参照の修正、二つの大文字SHOULDの通常表現への変更、Path・Query・Fragment中のbracket tokenが復元結果を変えうるという安全上の警告が加わった。公開記録には、これらを安定したreview IDと、採用・不採用・一部採用の理由へ結ぶ完全な表がない。

キューは公開済みの棚ではない

9月9日に第14版が提出され、ISEはRFC Editorへpublication requestを送った。IANAはIn Progressから9月16日にNo IANA Actionsへ変わった。RFC制作はAuthor Input Requiredで一度blockedになり、翌日にIn Progressへ戻った。RPC履歴はその後、reference checkingとformatting待ちからeditor assignment待ちへの移動を記録する。

RFC Editor公式queue XMLは締切時点で第14版をISE streamに置き、受領日を9月9日、assignmentをref_checkerとしている。Datatrackerとqueueは制作の異なる投影であり、一語の「承認済み」にまとめてはいけない。最終RFC番号もまだない。

Independent Submissionの説明には、reviewと改訂の反復、initial publication decision、RPCへの引き渡し、AUTH48、そしてpublicationという順序がある。RFCとしてreleaseされるまでISEは公開しない判断もできる。queue entryが証明するのは作業とcustodyであり、最終文書の成立ではない。

受け渡し記録の最小構造

最初の行は第12版の正確なハッシュと時刻をRFC 5742応答に結ぶ。各ballot/history commentには安定ID、提出者、本文ハッシュ、出所を持たせる。ISEはaccepted、rejected、partially acceptedのいずれかと理由を記し、採用項目は最初に実装した版と正確なdiff hunkを参照する。

同じ記録はIANA action、RPC blockの原因と解除条件、責任主体、最終RFC番号、stream boilerplate、後のerrataや後継文書まで伸ばせる。advisoryなコメントはadvisoryと明示し、他のreviewから生じた変更をballotの成果に付け替えてはならない。

この区別は安全上も重要だ。可逆なテキスト表記は偶発的なactivationを減らしうるが、IOCが悪性か、最新か、帰属が正しいかを検証しない。文書変更のprovenanceと脅威情報のprovenanceは別の記録である。

情報源