要約

  • recommended-min-versionが比較するのはメジャー、マイナー、パッチの数値だけである。YANG Semantic Versioning草案の第28版は、_compatible、_non_compatible、プレリリース情報、ビルド情報を比較から除外する。
  • 上位メジャー版も条件を満たす。また適格版が見つからなければ、コンパイラーは警告を出したうえでRFC 7950の規則に戻って処理を続けられる。解決完了と推奨条件の充足、実運用上の互換性は別の結果である。
  • 配備前には、要求、候補全集合、無視された情報、選択した正確なファイル、モジュール集合、feature、deviation、警告、クライアント試験、決定責任者、ロールバック先を結ぶ解決レシートが必要だ。これはDaniel Kadeの提案であり、IETFの規定ではない。

「最小」という言葉が安全性まで代弁してしまう

最小バージョンという表現は、運用の現場では強い意味を帯びる。セキュリティ基準なら、それを下回るものは拒否される。調達要件なら、それ以上の製品は要件を満たす。依存関係の宣言なら、数字が大きいほど新しく、少なくとも必要な機能を含むように読める。

しかしdraft-ietf-netmod-yang-semver-28の役割分担は異なる。2026年7月21日に公開された第28版は、Standards Trackを意図し、RFC Editor Queueにある現行Internet-Draftだが、まだRFCではない。同草案のrecommended-min-versionはYANGのimport文に付く拡張で、引数は三つの整数だけだ。

判定は、同じ数値三つ、同じメジャーとマイナーでより大きいパッチ、同じメジャーでより大きいマイナー、またはより大きいメジャーのいずれかを受け入れる。互換性修飾子とメタデータは見ない。草案が示す3.1.0の例では、3.1.2 _non_compatibleも4.1.2も合格する。前者は同じ枝で非後方互換の変更を明示し、後者はメジャー番号そのものが破壊的変更を示す。それでも数値上は候補になる。

これは偶発的な抜け穴ではない。草案は、規則を単純に保つための意図的な設計だと説明する。整合したモジュール集合を確保する責任はこの拡張の外部にあり、YANG packageなどで扱うことが想定される。つまり、拡張が答えるのは「この候補は数値条件を満たすか」であって、「このコントローラーに安全か」ではない。

一つの緑色表示が両者を区別しなければ、仕様が約束していない保証を組織が勝手に発行することになる。

バージョン情報は証拠であって保証書ではない

YANG Semverは変更履歴を読みやすくする。主系列のメジャー変更は非後方互換、マイナー変更は原則として同じメジャー内の後方互換、修飾子のないパッチ変更は編集上の変更を表す。YANG独自の修飾子によって古い保守枝も表現でき、_non_compatibleは同じ枝で維持されるため、後続の編集が過去の破壊的変更を見えなくしない。

さらに、アーティファクト名とセマンティックバージョンの組み合わせは、一つのリビジョンを一意に識別しなければならない。内容の異なる二つのファイルが同じ名前とバージョンを共有することは許されない。これはライフサイクル管理にとって重要な規律だ。

ただし、ラベルはモジュール作者の変更宣言であり、未知の利用者すべてを実行した結果ではない。仕様上は後方互換の追加でも、列挙型を閉集合だと思い込んだクライアントを壊すことがある。新しいノードがコード生成器の欠陥を露呈することもある。正しいラベルが、利用側の隠れた前提を正しくしてくれるわけではない。

単独ファイルの同一性にも限界がある。草案は、あるsubmoduleの内容とリビジョンが変わらなくても、別のsubmoduleにあるgroupingやtypedefが変われば、その意味が大きく変化し得ると指摘する。ハッシュは受け取ったファイルを固定するが、最終的なschema全体は固定しない。

したがって、セマンティックバージョンは作者が示す系譜の構造化証拠と位置づけるべきだ。暗号学的な内容証明でも、package lockでも、クライアント試験でも、配備承認でもない。

同じ「成功」に見える三つの状態

第一は推奨条件の充足である。リゾルバーが、その時点で見えた候補の中から数値規則に合うものを選んだ。この判断を再現するには、勝者だけでなく候補全集合を保存しなければならない。後日リポジトリに一つ追加されるだけで、選択は変わり得る。

第二はフォールバックによる完了だ。適格なモジュールが見つからない場合、草案はコンパイラーに警告を促し、その後RFC 7950の既存規則で処理を続けるよう求める。RFC 7950ではrevision-dateがあれば特定リビジョンを指定でき、なければどのリビジョンを使うかは同じ形では固定されない。schemaが出力されたとしても、失敗したsemver条件が満たされたことにはならない。

第三が配備受け入れである。確定したschema集合を、実際のコントローラー、収集器、生成器、設定、RPC、notification、state pathに当てる。残る不確実性と回復手段を見たうえで、変更責任者が承認する。

数値条件に通った版を旧クライアントが読めないこともある。フォールバックで構築できても、作者が想定したtypedefより古い版を得ることがある。コンパイルできても、新たに有効化されたfeatureで見える枝が変わることがある。三状態を一つの「build succeeded」にまとめると、技術的な完了が統治上の承認を乗っ取る。

判定対象は一つの番号ではなく解決済みschemaである

RFC 8525のYANG Libraryでは、datastore schemaはmodule setの集合として表される。module setには実装モジュールだけでなく、import専用モジュールとsubmoduleが含まれる。実装モジュールには対応するfeatureとdeviationも付く。内容が変わればcontent-idも変わる。

同じ基礎モジュールを名乗っていても、deviationがノードを制約または削除し、featureが新しい枝を開けば、クライアントが見る管理面は異なる。import専用モジュールの型変更も、複数の上位モデルへ波及する。互換性の単位を一つの勝者だけに縮めることはできない。

YANG Packages草案は、モジュール集合をバージョン付きの階層構造として扱う。packageは他のpackage、実装モジュール、import専用モジュール、featureを含められ、継承したモジュールやfeatureを除外することもできる。競合時には、たとえばhotfixの新しい版が自動的に選ばれる。古い版を選ぶには、元のpackageを明示的に精緻化した構成が必要になる。

packageは整合性管理を強くするが、名前と版だけで完全性を保証しない。草案はhotfixや論理グループ向けの不完全なpackageも認めており、依存関係の一部は利用環境で解決される。datastore schemaと結び付けた場合には、追加featureを含む解決結果がYANG Libraryのmodule setと完全に一致し、参照も完結しなければならない。これは構成の証明であり、個別クライアントの動作証明ではない。

Schema比較が測るのは変化であり影響ではない

YANG Schema Comparisonの草案は、二つのschemaの差を機械可読な形で記述するための仕組みを提供する。番号だけを見る審査よりはるかに有用で、どのstatementがどう変わったかを示せる。

それでも比較器は、特定バージョンのクライアントを動かさない。生成済みbindingの癖、あるleafが常に存在するというスクリプトの思い込み、未知のidentityに対する収集器の反応、新しいnotificationが制御ロジックへ与える作用は観測できない。ロールバックでschema、生成コード、保存設定、装置状態を同時に戻せることも証明しない。

互換性には必ず相手がいる。「差分が後方互換」と言うなら、比較した旧schema、分類方針、対象クライアントと試験負荷を併記する必要がある。柔軟なブラウザーに問題がないことは、静的型に依存するコントローラーの安全を意味しない。

解決レシートは捨てられた情報を拾い直す

解決レシートの起点はimportするモジュールだ。名前、リビジョン、完全なセマンティックバージョン、内容ハッシュ、取得元を記録し、要求された数値三つをそのまま残す。次に、ツールから見えた候補を完全版文字列、場所、ハッシュとともに列挙する。比較アルゴリズムは修飾子を無視できるが、監査記録は無視してはならない。

選択版については、正確なバイトまたは安定したダイジェスト、リビジョン日、版、取得来歴を固定する。さらにpackageの包含と除外、実装モジュール、import専用モジュール、submodule、feature、deviation、mount context、content-idまで展開する。各packageが事前に完全だったか、どの依存関係を現場で補ったか、競合をどの規則で解いたかも必要だ。

ツールの版と経路も証拠である。コンパイラー名、版、警告を保存し、semver条件を満たしたのか、失敗後にRFC 7950へ戻ったのかを区別する。schema比較を行ったなら、比較元、方針、結果を記録する。

最後にクライアント側の証明を加える。試験したコントローラー、agent、generator、collectorの版、代表的な設定、RPC、notification、state path、失敗結果、残存リスクの受け入れ責任者、配備範囲、有効期限、戻すべき旧集合を明記する。ラボでの合格は、同じリポジトリを使う全利用者の包括承認にはならない。

このレシートは仕様を複雑にしない。単純な検索規則に、組織が勝手な保証を背負わせるのを止めるだけだ。

参考資料