要約

  • 2026年9月5日付のdraft-dogru-cedulon-decision-profile-02は、IETFの支持や正式な地位を持たないindividual Internet-Draftであり、RFC streamも担当Area Directorもない。
  • このprofileは、署名付きDecision Recordと認証されたEffect Extractの行を照合する。allowには一つのeffectが期待され、denyまたはdeferには何も期待されない。
  • 改訂02は、bindingが二つの時計を順序付けないと明記した。行の時刻はextractのwindowに対して検査され、対応する決定時刻とは比較されない。
  • effect-against-refusalが示すのは、同じ参照番号の拒否と結果が監査対象に共存することだ。結果が拒否より後だったことや、制御経路の故障場所までは示さない。
  • 時系列を必要とするなら、時計の権限、許容誤差、補助証拠を別に記録し、「前」「後」「誤差内」「判定不能」を区別すべきである。

保存則と時系列は別の検査だ

Datatrackerは、この文書の制度上の位置を明確にしている。Emek Can Doğruによる改訂02のactive individual I-Dで、更新日は9月5日。誰でもI-Dを提出でき、この文書にIETFの支持や標準化手続上の正式な地位はない。RFC stream、Responsible AD、telechat dateはいずれも記録されず、IESG stateは「I-D Exists」にとどまる。

提案の監査モデルは分かりやすい。Deciderは、agentが行動してよいかをDecision Recordに署名する。channelまたはその活動を採取するprocessは、あるwindowで実際に生じたeffectの認証済みextractを提出する。verifierは一人のDecider、一つのchannel、一つのwindowについて、決定側と結果側をrefで結ぶ。

allowなら、同じref、effectHash、effectClassを持つ行が一つ必要になる。なければdecision-without-effect、Decision Recordのない行ならeffect-without-decisionとなる。denyとdeferはrefusalとして扱われ、対応する行があればeffect-against-refusalが出る。

ここで証明されるのは、二つの集合が期待どおり保存されていないことだ。「拒否した結果が起きた」という表示は自然だが、「拒否した後に結果が起きた」という時系列まで自動的には含まれない。固定された改訂02は、その不足を明記している。

先に記録された行も同じように結び付く

Decision Recordにもeffect rowにもtimestampMsがある。それでも、現在のbindingは両者を比較しない。行の時刻はEffect Extractが宣言する[windowStartMs, windowEndMs)の中にあるかだけを検査される。Decision Recordより早い日時の行でも、遅い行と同じようにbindする。照合対象はref、content、classであり、sequenceではない。

例えば、effectが10時00分、refusalが10時01分でもeffect-against-refusalは成立し得る。実際にeffectが先だった可能性もあれば、一方の時計が進んでいた可能性、決定後に署名だけが遅れた可能性、採取時に時刻が補われた可能性もある。人口差分の発見は正しくても、歴史の順序は未確定である。

windowの検査は別の役割を担う。範囲外の行が一つでもあればextractはmalformedとなる。windowの端に近い未照合項目は、隣のextractとの境界処理によってdeferまたはcarryされる。companionの既定値は五分だ。これは監査への所属と切り替え時の取りこぼしを扱う規則であり、二つの時計が五分以内で同期していることの証明ではない。

署名も時系列を生まない。署名は、ある鍵がその時刻値を含むbytesを承認したと示す。時計が正しかったこと、値がevent発生時に書かれたこと、後から埋められていないことまでは示さない。profile自身も、Decider側とEffect Extract側のtrust rootの関係は、運用上の独立性に依存すると述べる。同じprocessが事後に両方を整えれば、署名は正しくても時間証拠は条件付きのままだ。

「拒否違反」という物語を自動生成しない

effect-against-refusalを弱める必要はない。決定のないeffectとは異なり、ここには明示的なrefusalがあり、そのrefでeffectが見つかった。この区別は調査を前に進める。

一方、draftは、このfindingだけでは故障箇所を特定できないとも述べる。control delivery、enforcement、別経路、採取証拠のどこに問題があるかは、別の資料が必要だ。時刻についても同じ抑制が要る。「拒否refの下にeffectがある」は測定結果だが、「agentが拒否を受けた後に行動した」は順序、到達、実施可能性を追加している。

Heng Luの正確な記録に関する原則は、ここで有用な編集上の歯止めになる。記録は現実を記述し、現実を作り出さない。Cedulonの記録は、決定と結果と実行した比較を記述できる。比較していない順序を作ることはできない。これはDaniel Kadeによる限定的な適用であり、IETFやCedulonへの規範要求ではない。

四つの状態を持つsequence receipt

時系列の結果は、既存の保存則findingの横に置けばよい。一組のrecordがeffect-against-refusalと「sequence-indeterminate」を同時に持っても矛盾しない。前者は集合、後者は時間証拠の状態を表す。

比較の前に、receiptは両方の署名済みrecordをhashで特定する必要がある。それぞれのclock source、管理主体、採取方法、audit以前のcommitmentの有無を示し、許容skewとその根拠を残す。その上で結果を四つに絞る。

  • before — 不確実性を差し引いてもeffectがrefusalより前にある。
  • after — 同じ条件でeffectが後にある。
  • within-skew — 数値上の順序はあるが、差が許容誤差を超えない。
  • indeterminate — 出所、同期、補助証拠が比較を支えない。

monotonic counter、channel固有のevent sequence、trusted timestamp、checkpoint、独立観測は証拠を強くできる。ただし、Decider自身のcounterは独立性を保証せず、channelのsequenceはpolicyがいつagentに届いたかを保証しない。「after」が確認できても、それは公表した仮定の下での先後であり、因果関係や責任そのものではない。

実装は判定不能を通せるか

RFC 7942の形式を使ったImplementation Statusは、著者管理のcompanion repositoryに20件のconformance caseと4件のoffline fixtureがあると報告する。同時に、改訂02は文章だけを変え、caseを追加していないと明記する。二つの時計の順序は記述されたが、enforceされていない。live channel logの測定、独立実装、公開fixtureのtemporal precommitmentも確認されていない。

次の有効なテストは、明確なbefore、明確なafter、skew内、比較不能、事後入力を含むべきだ。価値は常に結論を出すことではない。証拠が足りないとき、verifierから報告、そして人や自動処理の判断まで「判定不能」が失われないことにある。

出典

  1. IETF Datatracker — Cedulon Decision Profile
  2. IETF archive — draft-dogru-cedulon-decision-profile-02
  3. Cedulon companion repository
  4. IETF Datatracker — Cedulon core draft
  5. RFC 7942 — running codeの認知を高める仕組み
  6. RFC Editor — RFCが作られるまで
  7. Heng Lu — The Bill of Rights of Uniqueness Coordination