要約

  • draft-ietf-netmod-yang-schema-comparison-09 は解析済みステートメントとコンパイル後の有効データツリーを比較し、変更を編集上・後方互換・非後方互換に分類する。
  • 分類結果はリビジョン審査、セマンティックバージョン、データ変換の設計に使える。一方、入力文脈の同一性、無損失移行、実装間相互運用、NACMの不変性、ローリング順序、稼働状態の収束までは証明しない。

差分が短いほど、結論は大きくなりがちだ。「非互換変更なし」という一行が変更申請では「安全」と読まれ、監視画面では「完了」に置き換わる。しかし比較ツールが観測したのは、特定の入力から得たモデル上の差だけである。アップグレード後に実行コードが何をしたかは、別の観測対象だ。

第09版は2026年7月3日に公開された。IETF DatatrackerではNETMODワーキンググループの現役Internet-Draftであり、RFCではない。現在の文書検証集計はエラー0、警告0だ。この状態は文書と検証面についての事実であって、ベンダー実装の採用、複数実装の一致、実ネットワークでの成功を示すものではない。

解析された木と有効な木

ドラフトが分ける第一の境界は、parsed schemaとcompiled schemaである。前者は読み込んだステートメントの木に近く、参照や変換がまだ完全には解決されていない。後者ではimportとsubmodule、uses、typedef、augment、deviation、refine、有効なif-featureが反映され、実効データノードの木ができる。

この二層は実務上必要だ。typedefの一箇所の変更が多数のleafへ広がることがある。別モジュールのaugmentが対象ツリーへノードを追加する。ベンダーdeviationは対象ファイルを変えずに制約を置換できる。ソースだけを見れば実効面を落とし、コンパイル木だけを見れば作者やimporterが確認すべきステートメント変更を落とす。

第09版はコンパイル済みデータノードの変更を先に出し、その後で残る解析済みステートメントを比較する。データノードを二重報告しない仕組みもある。さらにコンパイルIDには、旧新モジュールの名前とrevision、submodule、有効feature、再帰的importが含まれる。

したがって「差分なし」は、その入力一式に対してだけ成立する。別のfeature、別のimport revision、装置固有のdeviation、別submoduleでコンパイルした機器へ結果を横滑りさせてはいけない。最初に残すべき証拠は、ソース集合のハッシュと完全なコンパイル文脈である。

三分類には判断の出所がある

変更は編集上（ED）、後方互換（BC）、非後方互換（NBC）に分かれる。EDは有効なデータ値空間を変えず、import側も壊さない。BCは有効空間を広げてもimport側を無効にしない。それ以外、すなわち空間を狭めるかimportを壊し得る変更がNBCとなる。

単純な「型が広がった」という見方では足りない。uint32からuint64への変更は数値範囲を拡大するが、RFC 7951のJSON表現はnumberからstringへ変わる。そのためクライアント互換性を壊し、NBCになり得る。

pattern、when、mustの変更は既定でNBC、description、reference、presenceは既定でED、extension instanceは既定でBCとされる。作者はed-change-at、bc-change-at、nbc-change-atという持続的なセマンティックバージョン注記で既定値を上書きできる。

ここで重要なのは、上書きが判断を見える形にする点だ。観測結果へ変えるわけではない。固定規則、既定分類、作者による上書きを区別し、理由と承認者を保存してこそ、バージョンラベルは説明可能になる。

BCでも挙動は変わり得る

optional leafの追加は旧データを無効にしないためBCになり得る。しかしサーバーが新leafを生成すれば、クライアントのシリアライズ、ログ、ポリシー、画面表示は変わる。default変更は保存済み設定を触らず実効挙動を変える。whenやmustは検証経路を変え、featureとdeviationは装置ごとの実効表面を変える。

比較アルゴリズムはRPCを実行せず、既存設定を全件再生せず、default展開後のdatastoreを比較しない。RFC 8525のYANG Libraryはモジュール集合、feature、deviationのIDを与えるが、サーバーがそれを正しく実行する証明ではない。

RFC 8341のNACMも独立した境界だ。スキーマ差分が空でも、グループ、ルール、default-denyが変われば見えるノードと書けるノードは変わる。実運用の結論には、役割別の有効な認可行列を試す必要がある。

変換には「失ったもの」の記録が要る

ドラフトは比較出力が旧instance dataを新revision向けに変換するツールを助け得るとする。だが変換器は、廃止ノードの削除、enumの写像、defaultの挿入、表現の正規化、値の分割、保存不能データの拒否を自ら決める。

RFC 9195のcontent identityとprovenanceは、変換記録の有力な型になる。旧instanceのハッシュとスキーマID、変換器の版とrulesetを結び、削除・補完・正規化・合成・拒否されたノードを数える。出力をハッシュし、対象compiled schemaで検証し、どの往復性または意味的不変条件を試したかを書く。

対象スキーマにvalidであることと、意味が無損失であることは同じではない。二つの旧状態が一つの新状態へ潰れるなら、正しい形式でも情報は戻らない。その損失を受け入れる権限はデータ所有者にある。

比較後の門は実行して通す

次は実装試験だ。相互運用が必要なら独立したparserまたはserverを複数使い、代表設定とRPCを再生する。error-tag、default処理、canonical encoding、feature negotiation、影響を受けるNACM roleを確認する。binary、module set、flag、test vectorを固定し、緑の結果を再現可能にする。

続いて配備順序を試す。ローリングアップグレードでは、旧clientと新server、新clientと旧server、featureやdeviationが食い違うpeerが同時に存在する。差分は誰を先に上げるか、telemetryが途切れないか、新版が書いたデータを旧版が読んでrollbackできるかを証明しない。

最後にランタイムを観測する。RFC 8342がrunning、intended、operationalを分けるのは、設定、適用意図、観測状態が別物だからだ。比較結果からは、状態の収束、alarm、性能、外部利用者の結果は見えない。

第09版の価値は、スキーマ審査を再現可能な受領書にすることだ。その受領書を後続の実行証拠と取り違えないとき、三つのラベルは最も強い。

情報源

一次資料：YANG Schema Comparison 第09版、IETF Datatracker、YANG 1.1 / RFC 7950、YANG Library / RFC 8525、NMDA / RFC 8342、NACM / RFC 8341、YANG Instance Data / RFC 9195、YANG Semantic Versioning 第28版、YANG Module Versioning 第16版。 改訂の時系列はDatatracker履歴で確認できる。