要約

  • YANG 2.0はYANG 1/1.1を廃止せず、完全なデータモデルで複数の言語版を混在させる。ただし、includeとimportの許可方向は意図的に非対称である。
  • 旧モジュールAと2.0へ更新されたBを、revisionを指定しないimportによって同居させる例外は連鎖移行を防ぐ。しかし広告された一覧は、クライアントの選択、有効スキーマ、互換性、相互運用性、実運用を保証しない。

保守作業を具体的に考えよう。BはYANG 2.0へ更新された。YANG 1.1のままのAは、revisionを指定せずBをimportしている。サーバーは起動し、一覧にはAとBが現れ、監視画面も成功を示す。ここまでは草案の設計どおりであり得る。そこから「したがって全クライアントの契約も同じだ」と進むと、証拠のない飛躍になる。

revision 00の草案は2026年7月6日付で、YANG 2.0はRFC 6020やRFC 7950をobsoleteせず、一つの完全なデータモデルに複数言語版のモジュールを含められるとする。DatatrackerではNETMOD作業部会のActive Internet-Draftである。表紙はStandards Trackを意図しているが、現時点ではRFCでも実装実績でもない。

非対称性は移行の境界線

第12節では、YANG 2.0モジュールがincludeできるのは2.0サブモジュールだけで、YANG 1/1.1モジュールは2.0サブモジュールをincludeできない。旧言語のモジュールやサブモジュールは、revisionを指定して2.0モジュールをimportできない。一方、2.0側はYANG 1/1.1をrevision付きでimportできる。

これは相互に同じ意味の「後方互換性」ではない。新しい側は古い依存へ明示的に戻れるが、古い側は新しい言語のrevisionを前方参照できない、という移行方向の設計である。

特別規則は、旧版Aがrevisionを指定せずBをimportし、その後Bだけが2.0になった場合を扱う。サーバーはAとBを同時に実装でき、実装規則に従って両モジュールを広告し、Aと、YANG 1または1.1で記述されたBの最新revisionを広告することが推奨される。目的は明記されている。B一つの更新がA、そのimport元、さらに上流へと改稿を連鎖させることを防ぐためだ。

この抑制は重要である。言語移行を依存グラフ全体への同時命令にしない。Lu HengのMinimum Initial Specification, Localized Future Decision, and Voluntary Adoptionという枠組みで言えば、共通規則を薄く保ち、その先の採用判断を検証できる参加者へ残す設計だ。ただし判断が分散するなら、各参加者が実際に何を選び、何を動かしたかを示す必要も増える。

広告情報が証明する範囲

第5.6.4節は、サーバーが一つのモジュールについて複数revisionを実装してはならないとする。同時に、データノード等を実装するモジュールと、typedefなどのために参照されるimport-onlyモジュールを区別する。RFC 8525のYANG Libraryは、module set、実装/import-onlyの役割、feature、deviation、内容変更を識別する値を提供する。

この台帳は必須だ。観測時点でサーバーがAをどう掲載し、どのB revisionをどの役割で示し、どのfeatureとdeviationを宣言したかを残せる。しかし、クライアントがどのバイト列を取得したか、Aのrevisionなしimportをどう解決したか、二つのパーサーが同じスキーマ木を組み立てたか、実行中のクライアントがその広告状態を本当に使ったかまでは証明しない。

周辺仕様との境界もここにある。module versioningはrevisionの識別を改善し、Semverは許容範囲を表現し、packageは集合を記述し、schema comparisonは変更を分類する。ファイル名も候補を探す助けになる。どれも有用だが、resolverの選択、コンパイル結果、検証、実行の記録を置き換えるものではない。

共存から運用までの証拠階段

混在移行を承認するなら、少なくとも次の順序で証拠を残すべきだ。

  1. ソース同一性：モジュール/サブモジュールの正確なバイト列、由来、namespace、言語版、revision、ハッシュを保存する。
  2. 依存解決：import/includeの全閉包と、revision未指定の各辺でresolverが選んだ対象を記録する。
  3. サーバー宣言：YANG Library全体、conformanceの役割、feature、deviation、module-set識別子、観測時刻を取得する。
  4. 有効スキーマ：パーサー/コンパイラーの版、診断、augmentやfeature等の適用後に正規化したスキーマ指紋を残す。
  5. インスタンス検証：代表例と意図的な不正例を固定スキーマへ通す。parse成功は妥当性の証明ではない。
  6. クライアント選択：独立したクライアントのresolver traceを比較する。同じ一覧を読んでも選択は一致し得ない。
  7. 相互運用：read/edit、RPC、action、notification、障害、rollbackを混在境界で試す。
  8. 実運用：intendedとoperationalのdatastore、実際の挙動と回復を観測する。RFC 8342は設定意図と運用状態を明確に分けている。

この階段は合算される。上段へ進んでも下段の証拠は不要にならず、下段の宣言が上段の権威を借りることもできない。Lu Hengが論じるreality layersは、その誤配線を見抜く助けになる。広告、解決済み成果物、検証成功、運用結果は連続していても同一ではない。

YANG 2.0草案が与えるのは、不要な連鎖改稿を回避する手段である。証拠を省く近道ではない。言語版が一台のサーバーで共存できることと、特定クライアントに同じ契約が成立することは、別々に確かめなければならない。

参照資料