要約

  • RFC 10016は、システムが提供しクライアントには削除できない設定を示す、読み取り専用の<system>データストアをNMDAに加える。許可された範囲では、クライアントはそのノードを参照し、<running>で値を上書きし、システム定義の項目に設定可能な子ノードを加えられる。
  • origin=systemが示すのは値の供給元であり、人による承認、不変性、適用済みの事実ではない。上書きを消すと隠れていた値が<intended>に戻り、ハードウェア、ライセンス、機能、ソフトウェアの変化でも<system>の内容は動く。

変更票には「設定を削除」と書かれていた。担当者は、明示的な指定をなくせば値そのものもなくなると考えた。ところが再計算された<intended>には、以前から<system>にあった値が現れた。削除操作は空白を作る代わりに、隠れていた選択を有効にした。

この挙動は例外ではなく、RFC 10016が可視化する優先順位の帰結である。同文書はNMDAに、サーバー自身が供給する設定のためのconventional datastoreを追加する。クライアントからは読み取り専用だが、そのデータは有効設定を作る入力になり得る。

運用画面がread-onlyを南京錠のように表示すると、二つの異なる境界が混ざる。一つは、管理クライアントがどこへ書けるか。もう一つは、結果を変える要因が存在するかである。前者を閉じても、ブート、カード交換、ライセンス更新、ソフトウェア導入、<running>の上書きは後者を動かす。

見えなかった供給元をデータストアにする

RFC 8342のNMDAは、適用する意図と実際の運用状態を区別し、conventional、dynamic、learned、system、defaultなどの由来を扱う。RFC 10016では、<system>に存在する設定は、参照中か、適用中かにかかわらずsystem configurationである。サーバーが提供してもクライアントが削除できるデータは、この定義には入らない。

対応サーバーはietf-system-datastore identityを実装する。スキーマの土台はRFC 7950のYANGであり、クライアントはRFC 8525のYANG Library情報からサポート状況を発見できる。従来のように、製品固有の表示から「これは装置が作ったらしい」と推測する必要が減る。

ただし、system configurationには異なる生命周期がある。always-presentな設定は、特定の物理資源に依存せず、電源投入時に生成される。RFCの例はループバックインターフェースである。conditionally presentな設定は、カード、資源、ライセンス、機能といった条件が満たされたときだけ現れる。条件が失われればノードも消え得る。

<system>自体は再起動を越えて保持されるデータストアではない。サーバーは、その時点の条件に基づいて内容を再構成する。昨日と同じパスが今日もあることは、同一の入力が保存された証拠ではない。<running>だけをバックアップしても、次の<intended>を完全には再現できない。

書けなくても、勝敗には参加する

クライアントは<system>を直接編集できない。一方で、そこにあるノードを<running>から参照できる。サーバーが認める値なら同一箇所を上書きでき、システムが作ったリストエントリーの下に設定可能な子孫を追加できる場合もある。

マージでは、対応する<running>ノードが<system>より優先し、結果が<intended>になる。テンプレート展開やinactive configurationの除去などの変換が必要なら、二つのデータストアは独立に変換してからマージされる。元のツリーを並べた差分だけでは、どの値が勝ったかを確定できない。

システム値をA、上書きをBとする。Bがある間はBが勝つ。Bを削除してもAは消えない。クライアントには<system>のAを削除する権限がないからである。Aは<intended>へ戻り、適用条件を満たせば稼働状態に入る。したがって、上書きの削除は単なる片付けではなく、別の値を選ぶ政策変更である。

反対に、条件付きsystemノードがハードウェア撤去やライセンス変更でなくなることもある。関連する設定が<running>と<intended>に残っていても、対象資源がないため<operational>には現れない場合がある。意図は保存されていても、それを受け止める現実がない。

originは同意を記録しない

RFC 7952は、origin annotationに使われるメタデータの仕組みを定める。RFC 10016では、<system>から来て<running>で明示設定または上書きされていない構成はsystem originとして報告される。<running>由来の構成はNMDAの規則に従う。

この情報が答えるのは「どの供給元がノードを出したか」であって、「誰が今のリスクを承認したか」ではない。メーカーのプラットフォーム、ブートイメージ、ライセンス機構、資源管理部、ローカルプロセスのいずれも、人間の意思決定を介さず値を供給できる。<running>側も、自動コントローラーの出力かもしれない。

system originを「信頼済み」と読めば、製品の選択を組織の方針にすり替える。running originを「人が望んだ」と読めば、自動化の結果を個人の判断にすり替える。出所は説明責任の第一項だが、変更権限、審査、目的、リスク所有者を結び付けなければ承認記録にはならない。

intendedとoperationalの間は残る

RFC 10016は<system>が変わるたび、サーバーが<intended>を直ちに更新し、検証するよう求める。また、system configurationの変更後も<running>が有効な設定ツリーであることが望ましいとするが、その実現手段は範囲外である。これは処理上の保証であって、ハードウェアへの適用証明ではない。

同文書は<operational>を変更しない。RFC 8342の下では、資源の欠落、伝播遅延、適用失敗、残存状態によって意図と現実が離れる。<system>と<running>を別々に変換し、<intended>へマージし、条件付きで<operational>へ反映する。この各段階を一つの「設定済み」に畳んではならない。

変化の通知には、RFC 8639およびRFC 8641のYANG subscriptionとdatastore updateの仕組みを利用できる。通知の発行は観測点になるが、購読者が受信し、方針を再計算し、運用ツリーを再検証したことまでは示さない。

また<system>は<factory-default>の別名ではない。RFC 8808は工場出荷時データストアとfactory-reset操作を定義する。<system>は現在の条件でシステムが何を提供しているかを表す。値が偶然一致しても、時間軸と役割が異なる。

origin-and-precedence receipt

重要ノードごとに、出所・優先順位レシートを作れば、実効設定を追跡できる。最初にパス、値のfingerprint、origin、存在条件を記録する。条件には、ハードウェア、ライセンス、機能、ブート、ソフトウェアのepochを含め、「system値」を永続的な定数として扱わない。

次に、上書き可能性と勝敗を書く。どの<running>ノードが参照またはshadowしたか、追加された子孫は何か、双方にどの変換が走り、何が<intended>へ入ったかを残す。上書き削除の承認画面には、削除後に復活する値を明示する。

適用欄では、<intended>と<operational>を比較する。反映時刻、資源の有無、遅延、失敗、remnant state、そして「有効」と判断した観測証拠を記す。参照先が構文上正しくても活動中とは限らず、validな意図ツリーでも現物が欠けることがある。

権限欄では、system supplier、設定クライアント、運用承認者、リスク所有者を分ける。ソフトウェア更新、ライセンス遷移、カード挿入、policy commitを、それぞれ結果を受け入れた判断に結び付ける。機微情報を隠す場合も、hashと範囲を限定した参照は保存できる。

このレシートはDaniel Kadeによる編集上の統治案であり、RFC 10016が課す新要件ではない。目的は、見える供給元、マージの勝者、承認された判断、適用された結果を別々の事実として保つことにある。

セキュリティは読み取り制御から始まる

読み取り専用だから安全とは限らない。RFC 10016は、<system>にハードウェア識別子、セキュリティ方針、重要資源が含まれ得ると警告する。機微なノードやsubtreeへのアクセスを制限し、読み取り試行を記録する必要がある。RFC 8341のNACMはNETCONFおよびRESTCONF利用者のアクセス制御を提供する。

上書きは別の攻撃面になる。攻撃者や誤動作したクライアントが<running>へ値を書き、重要なsystem値をshadowすれば、<system>を一度も変更せずに方針回避や可用性障害を起こせる。<system>への書き込みだけを監視する仕組みは、そもそもクライアントが使えない経路を見張っていることになる。

RFC 10016は、装置側の設定を標準的に観察し、推論できるようにする。その価値を過大評価してはいけない。systemという出所は承認ではなく、read-onlyは不変ではなく、intendedは適用済みではない。可視化した値を、優先順位と運用結果まで追って初めて管理になる。

出典