要約

  • draft-ietf-nmop-network-incident-yang-14 は、ネットワーク側の raised・updated・cleared と、運用者側の acknowledged・diagnosed・resolved を別のライフサイクルとして扱う。
  • 一つの incident-resolve RPCは複数のインシデントを対象にでき、成功は後から別通知で届く。YANG Doctorsレビューは、通知を発端のRPCに対応付ける方法がないと指摘した。
  • 運用者は、要求、権限、対象、実施、通知、チケット変換、サービス確認を結ぶコマンドからclearedまでのレシートを持つべきだ。これは編集上の提案であり、IETF要件ではない。

「どのインシデント」と「どの要求」は別の識別問題

NMOPの草案は、異なるレイヤーから大量に上がるアラーム、性能指標、異常を、サービス影響を持つインシデントとして扱おうとしている。個別信号を減らし、確認、診断、解決を共通インターフェースに載せる狙いは実務的だ。

モデルには incident-no がある。通知にもRPCにも同じ番号を使えるため、どのインシデントの情報が更新されたかは追える。しかし incident-no はインシデントの識別子であって、呼び出し一回ごとの識別子ではない。

同じ57番に二つのクライアントがほぼ同時に作用すれば、後から届く57番の通知だけで発端を選べない。サーバーが自律的に復旧した場合や、観測条件が自然に消えた場合も同じだ。通知が正しいことと、通知の原因が証明されたことは両立しない。

草案は二つの時計を区別している

インシデント・インスタンスは raised、updated、cleared と進む。運用者の行為は acknowledged、diagnosed、resolved と進む。信号が消えても調査が続くことがあり、回避策でサービスが戻っても根本原因が残ることがある。この二分は、機械の観測と組織の判断を混同しないために有効である。

さらに運用上の考慮事項は、OSSのチケット状態との決定論的な変換を求める。ネットワーク側で閉じたのにチケットが開いたまま、あるいはチケットだけがResolvedになる「split-brain」を避けるためだ。

だが、決定論的であることは因果的であることではない。cleared を常にResolvedへ写せば画面は揃う。どの要求、どの承認、どの操作が元の状態を作ったかが欠けていれば、不確かさまで一貫して転記するだけになる。

非同期の結果には親子関係が要る

第14版では incident-resolve が複数の番号を受け取る。成功したインシデントは後続の別通知で cleared に更新される。具体的な解決方法は文書の範囲外だ。解決操作が稼働中サービスへ影響し得るため、影響が小さくないと判断したクライアントは実行しない選択もできる。

8月31日のYANG Doctors早期レビューは、この非同期境界を明示的に取り上げた。RPCの結果が通知で返る一方、どの通知がどのRPCの結果かを相関できないという指摘である。診断RPCについても同じ問いを立て、状態機械、識別子、空の対象リスト、エラー記述、通知の送信元と宛先の明確化を求めた。

レビュー結果は Almost Ready であり、次の未公開版を再確認すべきだとも記されている。したがって、現時点で言えるのは公開版に対する確認可能な指摘までだ。採用失敗、実装事故、後続版の欠陥を推定してはならない。

認証とNACMは必要だが、結果の親を示さない

草案はNETCONFまたはRESTCONFを安全な転送と相互認証で使うことを想定する。NACMはユーザーごとに操作とデータを制限できる。解決失敗には、推定原因が未解決、権限拒否、タイムアウト、資源不足などの理由がある。

これらは入口の統制を強くする。接続相手、呼び出し権、同期的な失敗理由を記録できる。しかし、認証済みの同じクライアントが再試行したとき、後着した通知が最初と二回目のどちらに属するかは別問題である。

認証主体、許可判断、要求受付、実行、観測結果を一語の「解決」に圧縮すると、アクセス制御が因果関係まで保証したように見えてしまう。NACMに不足があるのではなく、役割の違う証拠を一つの機構へ背負わせすぎている。

また、インシデント情報は壊れたネットワーク状態を露出し得る。悪意ある、または不具合を持つクライアントの大量操作は資源を消費する。補足レシートは公開ログである必要はない。詳細はアクセス制御下に置き、外部には操作種別、時刻、相関の確度、サービス確認だけを出せる。

複数対象では部分成功の所有者が問題になる

一つのRPCが61、62、63を対象にしたとする。61は予定した操作で復旧し、62は冗長系が自動的に迂回し、63は新しいトポロジー情報によって別インシデントへ再分類された。後に三つがすべて緑でも、元の命令が三つを直したわけではない。

一括処理の成功率だけを見ると、自動化コンポーネントに過大な成果を割り当てる。逆に、サービス影響を理由に危険な操作を止めた担当者の判断は見えなくなる。実行しない判断や代替策の選択も、最終状態と結ぶべき運用事実だ。

トポロジー情報の鮮度も効く。草案は、発見機構の停止や古い状態が、推定原因とサービス影響分析の精度を直接下げると説明する。知識の更新によってインシデントが変わる場合、変化を修復コマンドの成果にしてはいけない。

標準化プロセスの緑も範囲がある

第14版は2026年8月18日に公開された。ワーキンググループ最終確認は8月19日に始まり、9月3日に終了した。9月9日の凍結時点でDatatrackerはなお In WG Last Call と表示し、担当ADとIESGテレチャット日はない。第14版はStandards Trackを目指す活発なInternet-Draftであり、RFCでもIETFの最終承認でもない。

9月7日のYANG検証はエラー0、警告0だった。これは構文とモデル検査に関する明確な前進である。コマンドから通知、チケット、利用者の復旧までを一つの実装が追跡できる証明ではない。IETF 126のNMOP議事録にもキー、番号、IDの関係をめぐる問いが残る。

「相関不明」を許す証跡

コマンドからclearedまでのレシートは、まず呼び出し固有IDを作る。対象インシデントと版、認証主体と役割、NACMおよび変更方針の版、予想されるサービス影響、必要な承認、危険時の代替策を凍結する。

RPCの受付、対象ごとのエラー、サーバーとモデルの版、再試行や分割も残す。通知が来たら、そのイベントと時刻を呼び出しに結ぶ。結べないときは、自律変化または相関不明と記す。無理に成功の親を選ばない。

最後にOSSの変換規則、チケット担当者と時刻、サービス確認、残存原因や回避策、ロールバック所有者、後日の訂正を接続する。これはプロトコル拡張ではなく、運用側の証拠台帳である。

The Policy Mirrorの観点では、権限はNACM、意図はRPC、観測はデータストア、組織的完了はチケット、現実はサービス試験に書かれる。Running-Code Primacyは実行時にそれらを結ぶ。Reality, Not Advocacyが結論を限定する。草案は有用な状態語彙を作る。cleared が自分の原因まで証明するわけではない。

出典