要約

  • RFC 10035はYANG Libraryに読み取り専用のaugmented-byリストを加え、同じmodule-set内で、あるモジュールを直接augmentするモジュールをサーバーが示せるようにした。ベースモジュール自身の解析だけでは見えない外部逆依存である。
  • リストは推移閉包ではない。BがAの下にノードを追加し、CがBの定義した子の下に葉を追加する場合、AはBを、BはCを列挙する。CのパスがAから始まっても、Aの直接augmentとしては扱わない。
  • この情報は一台のサーバーが現在のライブラリで報告する直接隣接にすぎない。実効スキーマを理解したという主張には、content-id、revision、アクセス結果、クライアントの探索、ソース解析、実際の結果までが要る。

コードの依存を調べる作業は、ふつう現在のファイルから始まる。RFC 7950のYANGでも、importは利用する他モジュールを、includeは取り込むサブモジュールを、必要とする側が記述する。ソースを開けば、外へ向かう依存は読める。

ところがaugmentは逆から到来する。別のモジュールがベースのスキーマ木を指し、そこへ新しいノードを挿入できる。ターゲットを知っているのはaugmentする側であり、ベース側に訪問者名簿が追加されるわけではない。ベースだけを正しく解析しても、実効スキーマを取りこぼし得る。

2026年8月にStandards Trackで公開されたRFC 10035、YANG Library: Addition of the augmented-by Listは、この非対称性に小さな報告手段を与えた。RFC 8525を更新し、モジュール項目に読み取り専用のaugmented-by leaf-listを追加する。著者はZhuoyao Lin、Benoît Claise、Ignacio Dominguez Martinez-Casanuevaである。

Claiseを単独の発明者として描く必要はない。2026年8月31日に保存したIETF DatatrackerプロフィールにはRFC 10035を含む45件のRFCと、ネットワーク管理・運用、性能指標レビュー、IABワークショップ、YangCatalog支援に関する当時の公開役職が記録されている。IETF 104の略歴は、2012年から2018年までOperations and Management Areaの共同ディレクターを務め、YANG、テレメトリー、ネットワーク自動化に取り組んだ経歴を示す。これは共同標準化への文脈であり、特定サーバーへの権限や導入支配ではない。

外向きの依存と、外から来る依存

importとincludeは、必要とするソースに現れる。これに対し外部augmentは別ソースに書かれ、ターゲット側の形を変える。RFC 10035がaugmentとdeviationを逆依存として扱うのは、変化の宣言がベースの外にあるからだ。

RFC 8525のYANG Libraryはすでにdeviation moduleを示せたが、augmentについて同じ発見経路がなかった。クライアントが全カタログを検索して候補を集めても、それは特定サーバーの構成ではない。augmented-byは、サーバーが現在報告するmodule-setの中で答える。ベースとaugmenting moduleは同じmodule-setに掲載されていなければならない。

したがって、このリストは普遍的なモジュール間関係ではない。「このmodule-setで、このモジュールを直接augmentするのは誰か」という限定された問いへの回答である。全スキーマ木、実装適合、運用上の安全性までは証明しない。

直接性は親ノードの定義者で決まる

RFC 10035の三モジュール例が、誤読を防ぐ。Aがfoo-aを定義し、Bがその下にfoo-bを追加する。さらにCがfoo-bの下に葉を追加する。

CのターゲットパスはAの領域から始まる。だからCもAをaugmentすると数えたくなる。しかしCの新しい葉の親であるfoo-bを定義したのはBだ。ライブラリはAの下にB、Bの下にCを報告し、Aの下にはCを置かない。

これは情報不足ではなく、辺の意味を守る設計である。すべての子孫を祖先のリストへ複製すれば、直接関係とクライアントが計算した推移関係を区別できなくなる。どこで実際の接続が起きたのかも曖昧になる。

再帰的な閉包が必要なアプリケーションは、A→B→Cを自ら探索すればよい。特定のノード依存が必要なら、ソースを取得してスキーマ木を解析する。探索アルゴリズム、深さ制限、循環やエラーの扱いはクライアントの責任である。サーバーは最小の直接隣接を提供し、用途ごとの完成図までは作らない。

content-idが「いつの辺か」を示す

RFC 8525のcontent-idは、一台のサーバーにおける現在のYANG Library情報を識別し、情報が変われば値も変わる。クライアントはライブラリをキャッシュし、識別子の変化を見て再取得できる。RFC 10035も、新しいモジュールのオンボード時にライブラリとaugmented-byインスタンスを更新するよう求める。

そのため、A→Bだけを保存しても証拠として足りない。サーバー、管理エンドポイント、取得時刻、module-set、revision、namespace、content-idが必要だ。辺がない場合はさらに慎重でなければならない。直接augmentがないのか、情報が古いのか、RFC 10035未対応なのか、アクセスで隠されたのか、実装が誤っているのかを、欠落だけでは区別できない。

クライアントが閉包を計算したなら、サーバー応答とは別に、アルゴリズムの版、再帰上限、取得ソース、解析結果、経路とエラーを残す。これにより、後日module-setが変わったとき、ライブラリ変更とクライアント変更を切り分けられる。

読み取り専用でも機密になり得る

augmented-byは設定を書き換えない。しかし、どのオプションモジュール、機能、実装部品が存在するかを示し得る。RFC 10035は、標的型攻撃の助けになる可能性を挙げ、管理アクセス制御の境界で認可された利用者に読み取りを制限するよう勧める。

同じサーバーでも、主体によって見える情報が違い得る。何も返らなかったという観測は、空のグラフではなくアクセス結果かもしれない。認証主体と認可判断を保存する理由はここにある。

リストはYANG Libraryのサイズも増やす。運用者はオンボード時に更新し、クライアントはキャッシュの寿命を管理する必要がある。サーバーに万能の依存解析を担わせるのではなく、短い直接辺を正確に報告させ、必要なアプリケーションだけが深く探索する方が責任の境界は明確になる。

グラフから運用結果まで

A→Bが正しく報告されたとしても、クライアントが実効スキーマを理解した証明にはならない。Bの正しいrevisionを取得したか、解析できたか、B→Cを必要に応じてたどったか、deviationやfeature、datastore、アクセス範囲を扱ったかが残る。

さらに、モデルどおりにサーバーが動く保証もない。RFC 8342が扱うdatastoreの区別を含め、スキーマは期待を構造化する。実際の設定、状態、テレメトリー、オートメーション結果が、走っている系の証拠である。

ゆえに受領記録は、直接辺の先へ続く。ソース取得とパーサー結果、グラフを使った判断、対象datastore、期待したノード、観測結果、例外の所有者と修復を結ぶ。Running-Code Primacyはモデルを軽視する教義ではない。モデルから実行結果への飛躍を、証拠なしに許さない態度である。

情報源