要約

  • 同じ YANG モデルを別の場所にマウントしても、制約の評価に使われる親のデータまで同じになるとは限らない。
  • parent-reference が追加するのは XPath 評価のための参照範囲であり、マウント先の利用者に親のデータを読み書きする権限を与える仕組みではない。
  • モデルの納品と、周囲のモデルへの組み込みの受け入れは別の仕事である。参照関係の維持責任が曖昧なら、再利用で省いた作業が運用時の調整として戻ってくる。

移行の引き継ぎで、モデルのファイルと設定の候補がそろっていれば一安心できる。しかし、それだけでは再現できない判断がある。あるインターフェースを経路の送出先として指定できるかどうかは、そのインターフェースが装置内に存在するという事実だけで決まるとは限らない。どのネットワークインスタンスに割り当てられ、どの参照範囲に入るかも問題になる。

YANG Schema Mount は、既存の完全なモデルを別のモデルの下に置くための仕組みである。モデルごとに組み込み先専用の定義を書き直す負担を減らせる。その一方で、組み合わせを決める情報は、再利用するモジュールの外にも存在する。ファイルを持ち運べることと、同じ条件で評価できることを分けて考える必要が生じる。

この違いは、バージョン管理をさらに厳しくすれば消える種類のものではない。定義に一文字も変更がなくても、参照する周囲のデータが違えば、依存する制約の評価条件は変わりうる。引き継ぐべきなのは規則だけでなく、その規則が何を相手に判断するのかという説明でもある。

インターフェースはどこから見えるのか

RFC 8528 の付録 A.3には、ネットワークインスタンスの例がある。親にあるインターフェースを、そのインスタンスへの割り当てに基づいて選び、マウントされたモデルから参照できるようにする。これにより、インターフェースのモジュール自体がインスタンス側のスキーマに含まれていなくても、静的経路の送出インターフェースを参照できる。

重要なのは、インターフェースを何でも共有する例ではないという点だ。選択式は現在のインスタンスに結び付いたデータを取り出している。同じ式でも、評価を始めるインスタンスが違えば、対象となるインターフェースは違いうる。

この付録は非規範的な説明例であり、特定製品の実装を認証するものではない。現実の障害や通信断が報告されているわけでもない。それでも、何を確認すべきかは具体的になる。設定の候補を見るだけでなく、その候補が参照する親の選択結果も確かめなければ、判断の違いを説明できない場合がある。

組み込み先が受け持つもの

マウント点は親のモデルが用意するコンテナーやリストに置かれる。そこへ既存モデルを載せることで、再利用する側のモジュールに、あらゆる親構造をあらかじめ書き込む必要がなくなる。親と子の結び付けを外側で決めることが、この仕組みの利点である。

ただし、その結び付けを誰も管理しなくてよいわけではない。モジュールの保守担当者が示せるのは、まず定義の範囲である。実際にどこへ載せ、どの親データを参照させるかは、別の実装や運用判断に依存する。担当が分かれること自体よりも、境界にある判断が受け入れ確認から抜け落ちることが問題になる。

また、サーバーが示す schema-mounts は運用状態を記述する情報である。このツリーを見つけたからといって、そこを書き換えればすべての組み合わせを変更できるという意味にはならない。RFC は、下位の実装からデータを取り出す方法や、インスタンスを生成する詳しいライフサイクルを一律には決めていない。観測できる構造と、実際に操作できる入口を混同してはいけない。

参照できることと、取得できること

マウントされたモデル内のパスは、原則としてマウント点を根として解釈される。装置全体のデータが無条件で参照先になるのではない。共有スキーマ方式の parent-reference は、この範囲に親のデータを明示的に加える手段になる。

仕組みは XPath の評価に関わる。親の文脈で式を評価し、得られたノード集合とその祖先を、マウントされたモデルの XPath が評価時に利用できるツリーへ追加する。親の一部が、子の規則にとって意味のある参照先になる。

しかし、追加された親ノードをマウント側の NETCONF や RESTCONF 操作で読み書きできるようにするわけではない。制約の計算があるデータに依存することと、利用者がそのデータを取得することは別の関係である。どちらも「アクセス」と呼んで済ませると、設計上の区別が運用手順から消えてしまう。

パスの範囲を表す mount jail という言葉にも注意が必要だ。ここでの境界は、まずモデルのパスをどう読むかという境界である。プロセスが分離されている証拠でも、利用者間の安全性を単独で保証する仕組みでもない。名称から強い隔離を読み込むと、実際に必要な確認を省くことになる。

変わるのはどの制約か

RFC 7950で定められる YANG の must は、データが満たすべき条件を XPath の式で表す。葉参照には require-instance の区別があり、true なら対応する実体の存在に関する条件を満たす必要がある一方、false なら実体がなくてもよい。既定値や設定データを参照する際の規則もあるため、すべての参照を同じ存在確認として扱うことはできない。

親の割り当て変更により、あるネットワークインスタンスに選ばれるインターフェースが変わるとする。その集合に依存する制約なら、同じ設定候補に対する評価条件が変わる可能性がある。これは言語とマウントの規則から導く分析であり、特定のサーバーがどのように動いたかを観測した結果ではない。

反対に、親の変更が関係のないデータに限られるなら、対象の制約には影響しないかもしれない。選択後の集合が変わらない場合もある。正確な調査には、どの式がどのデータに依存するかという追跡が必要だ。「親が変わった」という説明だけでは、原因を特定したことにはならない。

参照先の種類を読み違えないことも基礎になる。RFC 8528 の別の付録例には、論理ネットワーク要素への割り当て欄にインターフェース名を入れてしまった誤りがあり、検証済みの編集上の訂正 5797で修正されている。正しくは論理要素の名前を指定する。これは親参照の方式を変更した訂正ではない。同じように見える識別子でも、何を指す欄なのかを確認する必要があるという、限定された教訓である。

同じスキーマでも、同じ状態ではない

共有スキーマ方式では、同じマウント点のインスタンスが共通のスキーマを使う。inline 方式なら異なるスキーマを使うことができる。運用状態の各インスタンスには YANG Library の情報が必要だが、inline の二つのインスタンスで内容識別子が一致しても、ライブラリーの内容まで一致するとは限らない。

さらに、共有しているのはスキーマであって、通常の親データの値ではない。インターフェースの割り当てが変わっても、その変化すべてがモジュール一覧の変更として現れるわけではない。ライブラリーの情報だけを記録しても、過去の参照文脈を丸ごと保存したことにはならない。

再利用を否定する必要はない。必要なのは、再利用によって省ける確認と、インスタンスごとに残る確認を区別することだ。移行先で同じモジュールが実装されていることは有用な情報だが、それだけで移行元と同じインターフェース集合を参照しているとは言えない。

権限については別に答える

NACM が実装されている場合、マウントされたノードへのアクセス制御は、組み合わされたツリー上の位置を通じて適用される。マウントしただけで、親と無関係な私有の権限体系が自然にできるのではない。データが読み取り専用になる条件も、誰に読み取りを許すかとは別に確認する必要がある。

RFC 8341は、データモデルの依存関係や暗黙の副作用による情報露出にも注意を促している。直接の読み取りを拒否しただけでは、許可された操作や関連データから利用者が何を推測できるかまで説明し尽くせない。ただし、これは一般的な注意事項であり、Schema Mount による具体的な侵害を示す証拠ではない。

参照があるから隔離に失敗している、と決め付けるのも、直接取得できないから隔離は完成している、と断定するのも早い。モデル、セッション、実際の権限と応答を確認して初めて、運用上の結論に近づく。設定の引き継ぎは、その違いを説明できる状態まで含めて考えたい。