要約

  • draft-ietf-netmod-yang-module-versioning-17 は非線形のmodule/submodule履歴を明示的に認める。revision dateは一つの不変な改訂を識別するが、祖先、意味上の順序、互換性までは示さない。
  • NBCマーカー、推奨最小日付、YANG Libraryの状態値はいずれも限定された宣言である。実効schema、サーバー挙動、クライアント実行、データ移行、配備順序、rollbackは個別に立証しなければならない。

同じモジュールに4月版と5月版がある。importは4月を最小日付として推奨しているため、5月版は条件を満たすように見える。だが5月版は別の枝から作られ、4月に追加されたgroupingを継承していない。日付の検査は通っても、依存関係は成立しない。

これがUpdated YANG Module Revision Handling第17版の中心的な変更だ。2026年6月29日に公開された文書は、まだRFCではなくInternet-Draftである。同じ親改訂から複数の独立したmodule/submodule改訂が派生することを認める。revision dateは一意であり続けるが、年代順、派生関係、後方互換性を含意しない。

履歴が示すのはグラフ上の一本の経路

各改訂のrevision historyは、その改訂が通ってきた系譜だけを列挙し、他の枝を網羅しない。したがってBがAから派生したかは、日付やversion labelの比較では決められず、Bの履歴を見る必要がある。

履歴は省略され得る。残ったNBC関係が正確なら、古い連続部分や一部の中間項目を削除できるが、最新項目は削除できない。この規則は偽の互換関係を防ぐものの、完全な系譜の保管を保証しない。実務上の証拠には、各版の正確なbytes、出所repository/archive、commit ancestry、削除された履歴の記録まで必要になる。

submoduleにも注意が要る。moduleはincludeするsubmoduleの正確なrevision-dateを指定するのが望ましい。指定がなければ、親moduleのidentityだけでは実際にcompileされた内容を再現できない。

NBCは責任ある警報であり、自動判定ではない

第17版はNBC変更を避けるよう求めつつ、bugfix、ノード廃止、不安定なモデルの再編などでは許容する。ある改訂が履歴上の直前版に対してBC規則を破るなら、rev:non-backwards-compatibleを付けなければならない。付いていない場合、変更はBCでなければならない。

方向は明確だが、事実認定は作者のreviewに依存する。形式上はBCでも、operational dataの値域拡大がclientへ大きな影響を与えるなら、保守的にマーカーを付けることもできる。逆に無印の信頼性は、変更分類と保存履歴の正確さを超えない。旧新bytes、変更一覧、適用規則、reviewerを一つの記録に束ねる必要がある。schema-comparisonの詳細なalgorithmは別文書の領域である。

最小日付は枝を選ばない

RFC 7950ではexact revision-dateをimportに指定できる。指定しなければ、どの版を使うかはYANG言語上未定義だ。厳密な固定が強すぎる場合に、rev:recommended-min-dateは依存を満たすと期待される最も古い日付を機械可読で示す。

toolはwarningを出せるが、このextensionはimportの意味もconformanceも変えない。ドラフト自身の例では、後の日付でも別枝なら必要な定義を含まない。この仕組みは直線的な履歴に向き、分岐の制約にはならない。

resolverの記録は、選択した改訂を特定し、必要版からの派生または必要定義の実在を示し、実際のfeatures/deviations下で全symbolを解決し、実効schemaのhashを残すべきだ。日付条件の通過は検証開始であって完了ではない。

二つのbooleanは申告の曖昧さを減らす

ietf-yang-library-statusはYANG Libraryにdeprecated-nodes-implementedとobsolete-nodes-absentを加える。前者がtrueなら、明示的なdeviationがない限りdeprecatedノードをcurrent同様に実装すると申告する。後者がtrueなら、obsoleteノードを一つも実装しないと申告する。既定のfalseでは挙動はunspecifiedだ。

両方trueなら、clientが見る申告schemaは明確になる。前者がtrueでない場合、clientはNBCマーカーだけに依存してはならない。しかしbooleanはserverの自己申告にすぎない。read、write、RPC、notificationを実行せず、deviationのloadや再起動後の一貫性も証明しない。実ノードを試し、宣言されたcatalogueとprocessがloadしたschemaを照合する必要がある。

Clientと永続データは別々の拒否権を持つ

NBC版serverは、自分のschemaには有効でも旧clientの想定範囲外の値を返し得る。ドラフトは防御的処理、履歴監視、移行前の具体的変更理解を求める。deprecatedノードは早期に利用を止め、obsoleteノードは必ず利用を止めるべきだ。

試験は旧client対新server、新client対旧serverの双方向で行う。encoding、default、RPC、notification、error handling、NACM roleを含め、binary、module set、feature、deviationを固定する。

永続instance dataは別の境界だ。RFC 9195はdata setをcontent-schemaに結び付けられるが、変換後のvalidationは意味保存を保証しない。rename、drop、synthesize、default補完、rejectを数え、semantic invariantとrollback後の可読性を試す必要がある。

RFC 8342がrunning、intended、operationalを分けるのは、設定、適用意図、観測状態がずれ得るからだ。import成功やschema validationだけでは、device convergence、段階配備中の相互運用、service outcomeは分からない。

第17版はYANGの進化を正直にする。日付は識別し、履歴は一本の祖先経路を語り、NBCは警告し、最小日付は助言し、YANG Libraryは報告する。実行されたclient、移行済みdata、観測されたnetworkが残りを証明する。

一次資料

凍結した公式資料は第17版、Datatrackerと履歴、RFC 7950、RFC 8525、RFC 9907、RFC 8342、RFC 8341、RFC 9195、Versioning Requirements第13版である。