要約

  • RFC 10016は、装置自身が供給する設定を公開する読み取り専用の<system>データストアをNMDAに加える。管理クライアントには書けないが、ソフトウェア、ライセンス、ハードウェアの変化で内容は動く。
  • 許可されたクライアント値は<running>からシステム値を上書きできる。上書きを削除するとシステム値が戻り、資源を外すと逆にクライアント設定だけが意図状態に残って実行されない場合がある。
  • 規格は変換、マージ、検証の順序を定めるが、適用成功、通知の完全性、無効化への対処、例外の所有者までは決めない。

「元に戻す」の戻り先

保守担当者が、数年前に導入したインターフェース設定の上書きを削除する。変更差分には一行の削除しかない。レビューも「標準値へ戻す」と記録して終わる。

だが、戻る値を確認した者はいない。装置はソフトウェア更新後、<system>に以前とは異なる値を供給していた。上書きが存在する間、その変更はマージ結果に現れなかった。削除によって初めて新しいシステム値が<intended>に現れ、適用可能なら実運用へ進む。

RFC 10016が標準化したのは、単なる新しい参照先ではない。装置が供給する設定とクライアントが明示した設定を別々の根拠として扱い、どちらがいつ優先されるかを明確にする仕組みである。

<system>は装置の供給値、<running>はクライアントの明示的な設定、<intended>は変換とマージを経て装置が適用しようとする目標、<operational>は実際に使われている状態を示す。同じパスに似た値が見えても、その出所と証明力は同じではない。

読み取り専用でも、装置は書き換える

管理プロトコルから<system>へ直接編集を送れば拒否されなければならない。この「読み取り専用」はクライアントの権限を制限する言葉であり、時間に対する不変性を意味しない。

装置は常時存在するループバックのようなノードを生成できる。カードが挿入された時だけ現れるノード、ライセンスや機能が有効な時だけ現れるノードもある。カードを抜く、機能を無効にする、ソフトウェアを更新すると、<system>は変化し得る。

さらに<system>は再起動をまたいで永続化されない。再起動時に現在の条件から再生成される。RFC 8808の<factory-default>は逆に、再起動をまたいで保持され、工場出荷状態へのリセットで読み書き可能なデータストアを初期化する。両方を「装置のデフォルト」と呼ぶと、復旧手順の意味が崩れる。

上書きと資源消失は逆向きに働く

サーバが許可するノードでは、クライアントが<running>に同じノードを書き、システム値より優先させられる。クライアントは<system>を書き換えていない。二つの入力をマージする時に、自分の値を勝たせている。

この上書きを消すと、元から存在するシステム値が<intended>へ復帰する。削除申請には、消す値だけでなく、その下で待っている現在のシステム値を表示する必要がある。そうしなければ、承認者は実際に有効化される値を見ずに判断する。

ハードウェアを外した時は別の形になる。カードに連動するノードは<system>から消える一方、事前設定したアドレスや説明は<running>と<intended>に残り得る。資源がないため<operational>には現れない。カードを戻すと、休眠していたクライアント意図が再び適用候補になる。

従って、上書き削除には「復帰値の確認」、資源削除には「未適用意図の明示」、資源復旧には「休眠設定の再審査」という異なる制御が要る。

マージ前の変換を混ぜない

RFC 10016は順序も限定する。テンプレート展開やinactiveノードの除去などが必要なら、<system>と<running>をそれぞれ独立に変換し、その後でマージする。許可された同一ノードでは<running>が優先する。<system>が変われば、サーバは直ちに<intended>を更新し、検証しなければならない。

一方で、システム変更後も<running>は有効な設定木であるべきだとしながら、その実現方法は規格の範囲外である。アップグレードで参照先が消えた時にコミットを止めるのか、代替値へ移すのか、旧ソフトウェアへ戻すのかは、実装と運用の責任になる。

RFC 8342が示す通り、<intended>は適用を試みる設定であって、適用済みの証明ではない。資源不足や遅延などのローカル要因で<operational>との差が生じる。管理APIの成功応答だけで実行状態を宣言してはならない。

見えるようになった情報を誰が扱うか

<system>により、クライアントは装置が供給する設定を標準的に取得できる。旧来のNMDAクライアントは従来通り動くが、新しい出所を理解して活用するには更新が必要である。

この可視性には機密性が伴う。ハードウェア識別子、セキュリティ方針、重要資源が含まれ得るため、RFC 10016は読み取り制御を要求し、アクセス試行の記録を強く勧める。RFC 8341のNACMを使えても、誰にどの範囲を許すかは運用者が決める。

書き込み側にも注意がいる。<running>の値が機密なシステムノードを覆えば、設定ミスや悪意によってポリシー迂回や可用性低下が起こり得る。供給元が読み取り専用でも、最終結果が安全とは限らない。

変更通知には RFC 8639 と RFC 8641 を利用できるが、on-change対応は全実装・全オブジェクトで一様ではない。受信側は対象範囲、同期時点、欠落を確認し、必要なら完全読み出しで再同期する責任を負う。

Heng Luのランニングコード優先という視点を重ねると、規格とコントローラはそれぞれ規則と意図を示し、<operational>が実際に成立した状態を示す。彼の最小初期仕様と将来判断のローカル化は、共通のマージ規則と、各運用者が持つ導入・停止・復旧判断を分離する根拠になる。