要約

  • draft-ietf-netmod-yang-versioning-reqs-14 は問題と五群の要件を定義し、特定の解決策を検討も支持もしない。
  • WG Document、I-D Exists、要件対応表、BC/NBC 表示は文書上の証拠であり、実装や移行の成功証明ではない。

審査会で、五行のチェック表が緑になった。各行には条項番号と関連ドラフトへのリンクがある。しかし、比較対象のバイト列も、旧クライアントの実行記録も、変換後データの損失表もない。問いが書かれたことを、答えが確認されたことに置き換えている。

revision 14 は 2026 年 7 月 20 日付で、本文の予定ステータスは Informational。Datatracker では NETMOD の active Internet-Draft、WG Document、IESG 状態 I-D Exists である。概要は、問題を記述し解決策への要件を定めるが、解決策そのものは扱わず支持もしないと明記する。

一群目には四つの異なる検査がある

NBC 更新が依存モジュール全体の同時改名を強制しないこと、変更されていないノードだけを使うクライアントへ影響しないこと、import を「任意」と「一版固定」の中間に制約できること、NBC を表現できることが求められる。

依存関係の閉包、分類の根拠、features/deviations を含む有効スキーマ、実クライアントの動作は別々に保存すべき証拠である。コンパイラが印を読めても、その分類やクライアント安全性までは証明しない。

二群目は BC/NBC の判定を人とツールに可能にする。ところが背景説明は、YANG statement が変わらず意味上の動作だけ変わる場合を認める。前後の成果物、比較規則、文脈、人的判断、警告を結び付けなければ、分類は由来のない宣言になる。

三群目の旧クライアント保護はペア固有の事実だ。旧クライアント対新サーバーと新クライアント対旧サーバーの双方で、read/write、RPC、notification、エラー、権限を試す必要がある。

四群目は deprecated ノードの実装有無、代替策と理由、obsolete 化前の予告を求める。広告値は重要だが、実際のノード、deviation、再起動後の継続性を観測しない限り、可用性の保証にはならない。

五群目は YANG 1.0/1.1 からの移行と instance data の解釈を説明させる。RFC 9195 の content-schema は出所を特定するが、別スキーマで意味が保持されたとは言わない。移行記録には rename、drop、生成、default、reject の件数、意味的不変条件、rollback 可読性が要る。

revision history、Semver、packages、schema comparison、filename、YANG 2.0 はそれぞれ一部を担いうる。本稿はそれらの仕組みを再論しない。要件表へのリンクは検査開始点であり、運用承認ではない。

一次資料

revision 14、Datatracker、履歴、NETMOD 一覧、RFC 2119、RFC 6020、RFC 7950、RFC 8049、RFC 8299、RFC 8525、RFC 9195 を凍結した。