要約

  • draft-ietf-netmod-yang-packages-09 は、includes、excludes、depends-on、モジュール、feature、deviation、mount を順序付きで解決し、resolved package schema を得る枠組みを示す。
  • 妥当な .ypkg、非循環な包含関係、complete: true、YANG Library の binding は有用なスキーマ記述である。しかし、内容の真正性、プロセスのロード、クライアントとの一致、インスタンス互換性、混在配備の安全性までは証明しない。

危険なケースは、解決に失敗したパッケージではない。すべてが緑に見えるケースだ。name/version は一意、JSON は妥当、包含グラフに循環はなく、URI は応答し、解決器は一貫したモジュール集合を返す。それでも、コントローラが古いキャッシュを使い、サーバが新しい内容を同じ name/version で提示すれば、双方の「解決成功」は異なるスキーマを指す。

第09版は2026年7月6日付の NETMOD 作業部会 Internet-Draft で、Standards Track を予定し、2027年1月7日に失効する。まだ作業中であり、実装や相互運用の事実ではない。価値は、暗黙のディレクトリを、計算可能な版付き階層へ置き換える点にある。

継承を解くと、最終形が変わる

includes はパッケージ、implemented module、import-only module、必須 feature を加える。excludes は継承したモジュールや feature を除く。depends-on は不完全なパッケージに必要な外部文脈を示すが、その項目は当該パッケージの resolved schema には入らない。mount は特定の mount-path に別のパッケージ集合を置く。

処理は二段階だ。まず included package を同じ規則で再帰的に解く。次に子の結果をローカル定義と併合する。implemented module は競合解決後にローカル指定で上書きされ、最後に除外される。import-only module では複数版を残せる。feature は和集合から追加・削除され、モジュール除外はその feature も落とす。

mount では inherit-packages=false が重要だ。true または未指定なら、継承した mounted package、追加 feature、parent reference にローカル値を足す。false なら継承側を捨て、ローカル定義がその mount のスキーマを置き換える。最上位のラベルが同じでも、下位の有効スキーマは大きく変わり得る。

location は参照の出現順に併合され、最初の URI が保持される。この順序は再現性を与えるが、URI の応答内容を認証する仕組みではない。

自動選択は意図を知らない

異なる implemented module 版が衝突すると、両方が YANG Semver なら major、minor、patch の数値だけを比較し、互換性修飾子、prerelease、build metadata は無視される。一方だけが Semver ならその版、どちらも違えば新しい revision-date が選ばれる。ローカルの includes/module は明示的に上書きできる。

規則は決定的でも、クライアントがどの版でコード生成したか、変更責任者がどの枝を想定したかは知らない。必要なのは成功フラグではなく、候補全体、比較規則、勝者、上書き、除外、警告を含む conflict receipt である。

schema comparison の差分分類は別稿の対象であり、ここでは繰り返さない。分類は判断材料になっても、比較対象が実際にロードされたバイトだとは保証しない。

complete が閉じるのは import の参照

referentially complete とは、直接・間接に含まれる全モジュールの import が、定義内の具体的なモジュール版へ解決できることを指す。不完全な hotfix や論理集合は depends-on で必要な文脈を示せる。

これは鏡像の真正性、同名同版の内容不変、submodule の実在、インスタンスの動作互換性を意味しない。submodule は主に取得場所を列挙するために記録され、解決はモジュール版を基準に行う。同版であれば情報が同等と仮定される場合もあるため、実バイトと閉包を別途固定する必要がある。

name/version の世界的一意性も、content hash ではなく発行規律だ。複数 location が異なる内容を返したとき、「等価であるはず」という規則だけでは正しい方を決められない。

サーバの一覧と datastore の実体は違う

トップレベルの package list はサーバが知る定義の一覧であり、実装中または datastore で有効であることを意味しない。YANG Library augmentation の package binding が、特定の datastore schema と package name/version、additional feature を結び付ける。

binding がある場合、その解決結果は referentially complete で、YANG Library module-set と完全一致しなければならない。強い整合要件だが、報告主体は同じサーバである。クライアントは両表現を照合し、時刻と content-id を保存すべきだ。content-id はサーバ内の変更検知子であり、システム横断のハッシュではない。

.ypkg は JSON の YANG instance data としてパッケージを運ぶ。サーバのコピー、location、同じ name/version のキャッシュを使える。構造検証は形式を証明するだけで、発行者、鮮度、再帰選択、実ロードを証明しない。RFC 9195 も instance data をライブな設定・状態操作プロトコルとは区別している。

適合性は実行結果より手前にある

標準パッケージを完全実装できないサーバは、元パッケージを include して版を変え、deviation を加え、モジュールや feature を除いた server implementation package を提示できる。差異を正直に表す仕組みであり、クライアントがその差異で安全に動く保証ではない。

証拠は順に分けるべきだ。発行者と package identity、取得したバイトと digest、構造妥当性、再帰 trace、競合選択、import/submodule closure、resolved schema、datastore binding、プロセス load、クライアントとサーバの集合、設定・状態・RPC・notification・アクセス制御の試験、配備順序と rollback、実行時状態、外部結果である。

一次資料

第09版と Datatracker の記録・履歴に加え、RFC 7950、RFC 8525、RFC 9195、RFC 8528、RFC 8342、YANG Module Versioning 第17版、YANG Semantic Versioning 第28版、IETF 122 NETMOD 議事録を参照した：