要約

  • draft-feng-netconf-naim-op-00では、補償を、実行済み変更の反転または緩和を意図したOperation IRオブジェクトとして表す。同時に、補償失敗、グループ実行のタイムアウト、ロールバック中の接続断を実装上の状態として挙げている。
  • 共通トランザクション識別子が与えるのは相関であり、全か無かのコミット、隔離、ロック、実行順、永続ログ、異種装置に共通する復元点ではない。
  • 復元を主張するには、前方操作と補償操作の実体、双方の認可と前提条件、並行更新、応答、事後の構成・運用状態、独立したサービス確認、取り消せない影響を分けて残す必要がある。

逆操作は、もう同じ世界には届かない

十台の装置に新しいルーティングポリシーを適用し、疎通確認に失敗したら旧ポリシーへ戻す。計画時点では簡単に見える。AIエージェントが意図を組み立て、Handlerが検証し、三台まで変更したところで四台目との管理接続が切れたとする。

その数秒で、別のコントローラが一台を更新しているかもしれない。外部の監視系は通知を受け取り、対向ネットワークは経路変化を観測し、担当者は障害手順を開始している。旧値の再投入は二台では正しくても、並行更新された一台では新しい正当な状態を壊す。接続断の装置では、要求が未着なのか、適用後に応答だけ失われたのかも分からない。

草案の定義は、この現実を隠していない。Compensation Operationは、先行操作の効果を「反転または緩和することを意図した」操作である。意図は結果ではない。緩和は復元より狭い成果でもあり得る。補償フィールドは、過去の再現ではなく、次に試みる行為を記述する。

Operation IRが分離する二つの役割

Operation IRは、自然言語の依頼とNETCONF、RESTCONFなどの実行プロトコルの間に、プロトコル非依存の表現を置く提案である。書込み、取得、RPC/action、フィルタ、datastore、前提条件、式、トランザクション情報、補償を持てる。AIは意図のエンコーダにとどまり、決定論的なHandlerがモデルに照らして検証し、ライブ状態を読み、プロトコルメッセージへ変換して実行する。

ただし、文書の地位は正確に扱う必要がある。Datatrackerは2026年7月18日付の00版を、アクティブな個人Internet-Draftとして掲載する。RFC streamも正式なIntended RFC statusもなく、IETFの支持を受けた文書ではなく、標準化過程で正式な地位を持たない。提出本文のヘッダーには「NETCONF Working Group」「Intended status: Standards Track」とあるが、これは提出者側の記載であり、ワーキンググループ採用やIETFコンセンサスの証拠ではない。

また草案は、自動的な補償導出アルゴリズム、スケジューリング内部、私有の実行ロジックを標準化しない。したがって、同じ前方意図から異なるHandlerが異なる補償列を作り得る。監査に必要なのは「自動ロールバック開始」という一行ではなく、生成された補償オブジェクトそのものだ。

識別子は一緒に数えるためのもの

第12節では、複数のOperation IRを共通トランザクション識別子で関連付けられる。ログを一つの案件として追跡するには有用だ。しかし、本文は原子的コミット、直列化可能な隔離、グローバルロック、強制順序、永続トランザクションログを定義していない。

一つのグループが異種の制御面をまたぐと、差は決定的になる。ある装置はcandidate datastoreとconfirmed commitを使え、別の装置はrunningへ直接書き、三つ目は外部作用を持つRPCを実行するかもしれない。同じ番号を付けても、能力と失敗境界は統一されない。

単純な逆順も安全とは限らない。ポリシー作成後にインターフェースへ参照を付けたなら、補償では参照解除が先になる。ところが別サービスがそのポリシーを利用し始めていれば、削除は新しい障害を作る。逆操作は、更新された世界に対する新規判断である。

補償には補償時点の権限が要る

草案は、通常操作と同じ認可、検証、ログの期待を補償にも適用すべきだとする。セキュリティ節は、補償操作の認可と実行・ロールバック監査を個別に挙げる。

前方操作の許可をそのまま使い回せない理由は明快だ。作成権限と削除権限は異なり得る。役割が失効しているかもしれない。動的参照の解決先が変わることもある。RFC 8341はNETCONF/RESTCONFの操作とデータノードを個別に制御する。「復旧」という目的は、アクセス制御を迂回する権限ではない。

前提条件は古い状態への上書きを防ぐ。期待値が成立しなければ操作を実行しない。しかし前提条件の成功は、その瞬間の読取りが一致したことしか示さない。書込みの適用、継続、サービス回復は別の証拠である。補償ごとに、主体、現行ポリシー、解決済み対象、観測値、認可判断、結果を保持すべきだ。

復旧経路にも故障モードがある

草案は、トランザクション対応実装に、前提条件失敗、途中失敗、補償失敗、グループ実行タイムアウト、ロールバック中の接続断への挙動を定めるよう求める。この列挙は、補償を失敗の外側に置かない。

送信直後の切断では、未実行と適用済み・応答喪失を区別できない。再送は非冪等な作用を重ね得るが、再送しなければ変更が残る。rolled_backという真偽値では足りない。計画済み、認可済み、前提確認済み、送信済み、応答済み、独立観測済み、サービス確認済みを分け、分からない状態を消さないことが重要だ。

NETCONFの限定的な保証と警告

RFC 6241のrollback-on-errorは、比較の基準を与える。サーバが能力を広告していれば、edit-configはエラー時に処理を止め、対象構成をその操作開始時の完全な状態へ戻せる。これは特定の能力、操作、構成範囲に結び付いた意味である。

それでもRFCは、共有構成でロックなしに使うと、他のNETCONFセッションの変更を誤って変更・削除し得ると警告する。rollback-failedも定義されている。confirmed commitには別の能力とcandidate datastoreへの依存がある。

Operation IRの補償は、NETCONFの機構、RESTCONFの補償書込み、アプリケーションactionへ別々に変換され得る。一つのバックエンドの強い保証を、同じ「rollback」という語だけで全体へ広げることはできない。

値が戻っても、起きたことは消えない

RFC 8342は意図された構成と運用状態を分離する。構成ツリーがスナップショットと一致しても、適用状態や学習状態、依存サービスが同じとは限らない。datastoreの外には、既に転送されたパケット、消費された通知、露出した資格情報、期限切れ、顧客アラーム、人の判断が残る。

補償が成功し、損害を十分に緩和することはある。それを価値の低い結果とみなす必要はない。問題は「補償完了」を「影響なし」「原状回復」と自動翻訳することだ。どの範囲が基準値へ戻り、どこが不明で、どの外部効果が残ったかを明示しなければならない。

dry-runは未知を表示してこそ有用になる

提案されるdry-runは実変更を行わず、対象、値、datastore、前提確認、プロトコル要約、補償計画、既知の副作用、制約を示す。ライブ状態、認可、外部条件を実行なしでは十分に確認できない場合、プレビューが不完全になり得るとも記す。

よいプレビューは、スナップショット依存の解決先、未確認の権限、模擬できない外部系、逆操作のない副作用を目立たせる。緑色の画面は意思決定資料であって、未来の証明書ではない。

復元を支える証拠列

保持すべきものは、変更前後のOperation IRだけではない。意図とコンテキストの版、Handlerの正規モデル、各認可判断、時刻付き前提読取り、生成メッセージ、応答・失敗・タイムアウトの順序、正確な補償オブジェクト、その認可と検証、ロックと並行書込み、事後の構成・運用観測、外部残留、Handlerとは独立したサービス試験が必要になる。

終端状態は「補償を試みた」「宣言した範囲のモデル状態が戻った」「サービスが復旧した」の三つに分けるべきだ。前の項目は次の項目を自動的に証明しない。識別子は証拠を結ぶが、証拠の代わりにはならない。

出典