要約

  • IESGは2026年8月18日、draft-ietf-netmod-yang-module-versioning-17をProposed Standardとして発行することを承認した。文書は非後方互換なモジュール更新を明示し、importにrecommended-min-dateを加え、deprecatedおよびobsoleteノードの実装状態を見えるようにする。
  • 文書自身の分岐例では、2019-05-01改訂が2019-04-01という推奨下限を満たしても、2019-04-01の枝で加えられた内容を持たない場合がある。日付は成果物を並べるが、子孫関係、対象上の実効スキーマ、導入を決める権限までは示さない。

日付の門を通ったのは隣の枝だった

冒頭は仕様書の例から作った分析上の場面であり、実際の装置、ベンダー、ネットワーク障害の報告ではない。リゾルバーはrecommended-min-dateの定義どおり、指定日と同日またはそれ以降の改訂を候補にしている。

構造は2019-02-01で二つに分かれる。一方は2019-03-01から2019-05-01へ進み、他方は2019-04-01から2019-06-01へ進む。2019-04-01で導入された機能が必要なら、その日を下限にできる。2019-05-01は数値上は合格するが、系譜上は兄弟の枝である。

草案は、2019-05-01が2019-04-01で求める内容を持たない可能性を明記し、この仕組みは分岐履歴には適さず、直線的な開発で最も役立つと述べる。ここで壊れているのは日付計算ではない。「後の日付」と「そこから派生したもの」を同じ判定にしたことだ。

承認された文書は非互換な境界を可視化する

承認対象はNETMOD作業部会の“Updated YANG Module Revision Handling”である。まだRFC Editorの待ち行列にあるInternet-Draftで、発行までに編集上の変更が入り得る。IESGの通知は実装状況を不明としており、広い製品対応を意味しない。

RFC 7950は厳格な後方互換更新を求めてきた。新文書は、実装に合わせた不具合修正、obsoleteノードの除去、不安定なモデルの整理、互換性を保つ改造の費用が過大な場合など、非互換な変更が必要になる局面を認める。ただし最小化する原則は維持される。

親改訂に対して非後方互換な変更があれば、revision文の下にrev:non-backwards-compatibleを置かなければならない。これにより無言だった境界が検査可能になる。しかし印が説明するのは親子の一辺であり、必要な機能の枝から候補へ道が続いていることではない。

不変の識別子にも分岐した家系がある

一つの履歴内では、モジュール名と改訂日が特定の不変な定義を識別する。日付には強い識別能力がある一方、系譜を推論する能力はない。二つのモジュールやサブモジュールの祖先関係は、日付や版識別子だけでは決められず、履歴を参照する必要があると文書は説明する。

includeがサブモジュールの正確な改訂日を拘束しない場合、親モジュールだけから実際に組み込まれた内容を確定できない。正確なrevision-date、YANG Library、またはパッケージ在庫が必要になる。

したがって導入記録には、選択日だけでなく、成果物のハッシュ、親辺または枝の経路、サブモジュール改訂、対象が解決したモジュール集合が要る。不変のファイルを指していても、間違った家系に置けば判断は誤る。

推奨下限は固定し過ぎないための仕組みである

recommended-min-dateはimportに零個または一個置ける拡張子文である。読み込む改訂の日付が同日以降なら従っていることになり、この値の追加、変更、削除自体は後方互換と分類される。理解しないパーサーはRFC 7950の通常のimport処理を続ける。

草案は依存の下限を示したいとき、厳密なimport revision-dateよりこの方法を推奨する。特定日の固定は依存を強くし過ぎるからだ。後続の互換な改善を取り込めるという利点は明確である。

その柔軟性には別の適合性確認が必要だ。日付条件は候補を広げるだけで、必要な改訂の子孫か、ノードを保つか、既定値が同じか、クライアントに安全かを尋ねない。日付で候補を探し、履歴と実効スキーマで絞ることが、固定と無検査の間にある実務的な解である。

非互換の印は一つの辺に付く

rev:non-backwards-compatibleは、ノードがobsoleteになった、制約が変わった、または許容される別の非互換変更が起きたことを警告できる。親との関係を表すもので、分岐グラフ上の全改訂との関係を保証しない。

一覧画面が「最も新しい日付」と「警告の有無」に証拠を圧縮すると、この違いは消える。依存機能は別の枝で生まれているかもしれない。選択行に警告がないからといって、存在しない祖先辺は生まれない。

形式上は互換でも、運用上のleafの値域拡大などクライアントへの影響が大きいと保守者が考えれば、この印を付けられる。保守的な注意信号であり、自動承認でも自動拒否でもない。スキーマ比較は変化を説明し、対象試験は動作を確かめる。それぞれ別の不確実性を減らす。

履歴を削ると証明できる範囲も縮む

長い履歴を短くする、古いimportを避けさせるといった目的で、公開済みrevision文の一部を除ける。ただし最新項目は残し、残る非互換の印が、残った項目間の関係を正確に示さなければならない。

草案は、非互換変更が導入された時点を見えなくするため削除を推奨しない。中間項目を消した結果、隠れた非互換段階をまたいで後続改訂が互換に見える場合、その削除は認められない。

履歴保持は運用証拠である。標準上の履歴が必要な辺を残さないなら、成果物庫、署名済みハッシュ、パッケージ目録、変更記録で再構成可能な鎖を保存しなければならない。表示を簡潔にするだけの削除が、将来の導入根拠を失わせることがある。

ノードの状態は対象ごとに確かめる

新しいietf-yang-library-statusはYANG Libraryに二つの真偽値を加える。deprecated-nodes-implementedがtrueなら、deviationで明示的に除かれない限りdeprecatedノードをcurrentとして実装する。obsolete-nodes-absentがtrueなら、obsoleteノードを実装していない。

両方の既定値はfalseだが、falseは反対を保証せず、振る舞いが未指定という意味である。草案は正確なスキーマをクライアントが判断できるよう、両方をtrueにすることを推奨する。前者がtrueでなければ、互換性の判断を非互換の印だけに依存できない。

正しい枝を選んでも、対象がdeprecatedノードを既に除いたり、obsoleteノードを残したりしていれば結果は異なる。ライフサイクルはcurrentからdeprecatedを経てobsoleteへ進め、クライアントはdeprecatedの利用終了を計画し、obsoleteの利用を停止しなければならない。これは移行作業であり、日付の属性ではない。

導入判断にはグラフと稼働対象が要る

防御可能な制御系は、必要機能と導入改訂を記録し、正確な成果物を解決し、そこから候補までの親経路を証明する。不互換辺と履歴の欠落を保存し、サブモジュールを固定し、YANG Libraryと二つの状態値を取得し、deviationを適用して実効スキーマを構築し、代表データを検証する。

さらに実際のサーバーソフトウェアと設定区分に対してクライアントを試す。新しいスキーマが旧クライアントの想定外の値を返し、既定値を変え、NACM規則の調整を要求する可能性がある。日付比較からは見えない。

失敗の種類を混ぜてはならない。新しい兄弟枝なら系譜障害、状態宣言の欠落なら対象発見の空白、木の差ならスキーマ障害、値域や既定値の差なら実装結果、承認者不在なら統治障害である。日付は有用だが、候補を開く権限までしか持たない。子孫関係、対象の証拠、稼働試験、責任者が導入を閉じる。

情報源