要約

  • RFC 5277 では、指定した開始時刻が保持済みログより古い場合、利用可能な最初の通知からリプレイを始められる。そのため replayComplete が正しく届いても、依頼した期間の前半は欠けたままである。
  • 完了の対象は、保持された履歴、ストリームの所属、フィルター、セッション権限の交差部分に限られる。受信、保存、時刻の正確さ、アプリケーション処理は別の証拠で確かめなければならない。

完了フラグの主語を取り戻す

技術的な事故調査では、短い語ほど強い権限を持ちやすい。「complete」はその典型だ。RFC 5277 の replayComplete は、対象となるリプレイ通知をサーバーが送り終えたという、よく限定された合図である。歴史そのものが完全だという宣言ではない。

クライアントが時刻 A を要求し、現存ログが時刻 B からしか始まらない場合、サーバーは B から送る。A から B までを復元する義務はなく、その区間にイベントがなかったと認定することもない。それでも適用可能な通知を送り終えれば、マーカーは正当に現れる。

したがって、調査記録には「要求開始」と「有効開始」の両方が必要になる。差分を消して成功だけを残す設計は、観測結果を改善するのではなく、証拠の意味を拡張してしまう。

なお、RFC 8639 は購読通知の枠組みを更新し、RFC 8641 は RFC 5277 の通知管理スキーマを YANG に変換した。本稿は RFC 5277 の境界を読むものであり、2008 年の方式だけが現在の選択肢だと主張するものではない。

保存期間が決める見えない左端

リプレイ機能は任意であり、通知のロギングに依存する。何件、どの期間を保存するかは実装に委ねられている。replayLogCreationTime が古いからといって、その時点からの通知がすべて残っているとは限らない。

ログは一度作成された後も、内部の古い項目を順に失い得る。RFC 5277 が示す replayLogAgedTime は、その老化を理解する手掛かりになる。コンテナの誕生日と、現在読める最古の内容は別の時刻だ。

運用側はログの世代、リセット、保持ポリシーの版、最古・最新の実観測通知を一緒に保存すべきである。開始点が後退したとき、それを「正常な短縮」と扱うだけでは不十分だ。調査可能性が失われたというリスクとして管理する必要がある。

ストリームは全世界ではない

イベントストリームは転送条件に合う通知の集合である。既定の NETCONF ストリームが含むのは、そのサーバーが対応する NETCONF XML イベント通知であって、管理対象内のあらゆる変化ではない。

内部イベントが通知になるか、どのストリームへ属するか、独自ストリームがどう構成されるかには、RFC の外側にある実装と運用の判断が入る。ある通知が見つからないという事実だけで、元の状態変化が起きなかったとは言えない。

さらに、同じ名前のストリームでもアップグレードや設定変更で中身が変わり得る。長期監査には名称だけでなく、定義の版と通知生成契約が要る。そうでなければ、異なる観測窓を同一の記録源として比較することになる。

利用者ごとに異なる過去が生成される

購読時のフィルターは、どの通知を転送するかを絞る。通知要素が生成された後にはアクセス制御も適用され、セッションに権限がなければ、その通知は当該セッション向けに破棄される。

同じ期間を照会した二人が、異なる結果を得ても不思議ではない。どちらも正規の結果であり得る。違いを解く鍵は、フィルター本文、認証された主体、アクセス制御ポリシーの世代、そして可能なら各段階の件数である。

replayComplete は、そのセッションに適用された過去を閉じる。権限で見えなかった通知や、フィルターで除かれた通知の不在証明にはならない。監査中に権限が変われば、再実行結果も変わる。その変化をログ改ざんと誤認しないためにも、可視性の条件を証拠として固定する必要がある。

購読の成立と一件ごとの受領は別物

create-subscription に対する肯定的な RPC 応答は、サーバーが要求を受理したことを示す。その後の通知は一方向で、RFC 5277 は通知ごとの応答を規定していない。機能広告も、個別のイベントが生成・送信・保存された証明ではない。

セッション断、送信キューの損失、デコーダー拒否、クライアントの永続化失敗は、受理後に起こり得る。サーバー側の送信が正しくても、利用側の履歴には穴が開く。端から端までの完全性には、受信側チェックポイント、識別子またはシーケンス、保存成功の証跡が欠かせない。

notificationComplete との区別も重要である。replayComplete は履歴部分の終端、notificationComplete は停止時刻を持つ購読そのものの終端を示す。二つを単一の「完了」状態へ畳み込む画面は、どの境界が閉じたかを失わせる。

履歴からライブへの継ぎ目

停止時刻のないリプレイ購読では、履歴分の後に、購読作成以降に生成された通知が送られ、続いて通常のライブ通知へ移る。マーカーはこの境界を示すが、継ぎ目で欠落も重複も順序逆転もないことまでは保証しない。

連続性が重要なら、生成元の世代、利用可能なイベント ID や連番、送信・受信・保存時刻を残す必要がある。eventTime はイベント源がイベントを生成した時刻だ。受信時刻ではなく、時計同期の品質保証でもない。時刻順に並べただけの年表を因果関係と取り違えてはならない。

証拠として残すべき項目

高い確度を要する調査では、少なくとも次を一組にする。

  • 認証したサーバー、NETCONF セッション、利用主体；
  • 通知機能とストリーム発見の応答；
  • ストリーム名、定義版、リプレイ対応状態；
  • 要求した開始・停止時刻と実際の有効開始；
  • ログ作成、老化境界、リセットまたは世代；
  • 実際に観測した最初と最後の通知；
  • フィルター本文とアクセス制御ポリシーの世代；
  • 購読 RPC 結果とサーバー側購読 ID；
  • 二つの完了マーカーとクライアント受信時刻；
  • リプレイからライブへの継ぎ目、欠落、重複；
  • eventTime、送信、受信、解析、永続化の各時刻と結果；
  • 通知の主張を照合する権威ある状態または業務結果。

最終文は「B から C の間で、保持され、このストリームとフィルターと権限に適用された通知のリプレイが完了した」と書くべきだ。条件を省けば読みやすくなるのではない。別の、根拠のない断言になる。

Sources