要点

  • NETCONF ワーキンググループの現行ドラフトは、YANG-Push にモジュールの特定 revision または互換なセマンティック version の制約を加え、開始・変更通知に版と YANG Library の content-id を載せる。
  • これはスキーマのずれを拒否・検知する手掛かりである。import 先の互換性、受信側が実際に読み込んだスキーマ、変換後の意味、操作権限、ネットワーク上の効果は、それぞれ別の証拠を必要とする。

テレメトリー運用では、無通信は分かりやすい。到着件数が落ち、遅延が伸び、接続アラームが鳴る。厄介なのは、メッセージが平常通り流れ続ける場合だ。選択したデータの形や意味だけが変わっても、配信監視は緑のままでいられる。

YANG-Push の設定済みサブスクリプションは、再起動やソフトウェア更新を越えて残り得る。一方、データの意味を構成する YANG モジュール、revision、import、deviation、identity の集合は更新される。永続化された指示と、現在のスキーマ集合は同じ寿命を持たない。

この差を扱うのが、2026 年 9 月 17 日付の draft-ietf-netconf-yang-notifications-versioning-16 である。Datatracker 上では NETCONF ワーキンググループの活動中の Internet-Draft で、Proposed Standard に向け IESG に提出され、9 月 29 日まで IETF Last Call に置かれている。最終 RFC でも、製品認証でもない。

ドラフトの価値は、サブスクリプションが依存する版を明示し、ライフサイクルの変化として通知できる点にある。暗黙だった前提を、拒否理由と監査可能な状態へ変える。ただし、その証拠が届く範囲を越えて結論を広げてはならない。

日付を固定する契約と、互換範囲を受け入れる契約

revision はモジュールの特定日付を要求する。再現性を優先する仕組みに向く。公開側がその revision を提供できなければ revision-unsupported を返し、近い版へ黙って置き換えない。

version は条件を満たす最新の互換 YANG セマンティックバージョンを求める。互換範囲内の進化を許す選択である。該当版がなければ version-unsupported、revision と version が矛盾すれば incompatible-revision-and-version となる。いずれも application の invalid-value RPC エラーとして表現される。

固定と互換範囲には別の運用コストがある。固定は監査しやすいが、更新時に意図的な停止を招く。互換範囲は調整を減らすが、変更の分類と受信側の実装に信頼を置く。経路制御を自動実行する系と、参考値を表示する画面を同じ設定にする理由はない。

設定済みサブスクリプションでは再起動後の照合が重要になる。保存した制約が現在の YANG Library と合わない場合、公開側は subscription-terminated を送る。設定が残っているという事実は、互換性を作り出さない。

継続できる場合も、状態は明示される。subscription-started と subscription-modified にモジュール名、revision、任意の version、yang-library-content-id が加わる。稼働中の revision または version の変更はポリシー変更として扱われ、subscription-modified を発生させる。

正しい revision は受信プロセスを更新しない

公開側が要求通りの revision を報告しても、収集側が正しいファイルを読み込んだとは限らない。スキーマレジストリには新版があっても、稼働中の worker は古い生成コードを保持しているかもしれない。新しい identity をパーサーが受けても、保存層が不明値へ落とすこともある。

さらに、変換処理が新しいパスへ出力し、ルールエンジンだけが旧パスを読むこともある。各プロセスのヘルスチェックは成功する。意味の連続性だけが壊れる。この種の障害は、アプリケーション境界で初めて現れる。

必要なのは revision の記録を running code の記録へ接続することだ。公開側と受信側の build、サブスクリプション ID、要求制約、実効モジュール集合、YANG Library スナップショット、読み込んだスキーマのダイジェスト、デコーダーと変換処理の版、再生テスト結果を一つの追跡単位で保持する。

Datatracker が 9 月 28 日に示した ietf-yang-push-revision モジュールの検証結果は error 0、warning 0 だった。これはモデル成果物に対する有益な検査結果である。ルーター、コレクター、キュー、判断処理の動作を観測したものではない。標準の品質と導入結果を混同しないことが Running-Code Primacy の出発点になる。

互換という宣言は、消費者ごとの実行試験を終わらせない

YANG Module Versioning と YANG Semantic Versioning は、後方互換な変更と非互換な変更を記述する共通語彙を整える。これにより、受信側は合理的な version 条件を要求できる。しかしモジュール作者は、全ての利用側の偶発的な依存を知ることはできない。

互換とされた任意ノードの追加がコード生成器の欠陥を踏むことがある。新しい列挙値がデフォルト分岐に入り、異常を正常として扱うこともある。型の範囲拡大が保存形式の限界を越える場合もある。モデル契約を破っていなくても、個別のパイプラインは壊れ得る。

したがって「最新の互換版」は試験を開始する条件であり、試験完了の印ではない。選択パスから import と identity をたどり、候補スキーマを実際のデコーダーへ読み込み、通常値、境界値、未知値を再生する。高影響の自動化なら、結果が一致するまでデータを隔離する。

全ての変更で停止する必要もない。依存関係の差分が対象外で、再生結果も同じなら継続できる。共有プロトコルは小さく確かな版シグナルを提供し、各利用側は用途に応じて継続、縮退、審査、停止を選ぶ。この分担は Minimum Initial Specification の考え方に沿う。

import 先の変化を content-id が広く知らせる

YANG では typedef、grouping、identity を別モジュールから import する。サブスクリプションが直接参照するモジュールの revision が変わらなくても、意味を支える依存モジュールは変化し得る。直接版だけを見る検査には盲点が残る。

RFC 8525 の YANG Library content-id は、現在のライブラリ情報に対する実装固有の識別子である。値が変われば、装置全体のスキーマ集合が動いたと分かる。直接モジュールに現れない変化を調べる入口になる。

ただし粒度は粗い。対象パスと無関係なモジュールの追加でも変わり得る。どの依存が変わったかは示さない。異なる実装間で普遍的な内容ハッシュとして比較するものでもない。変化は「新しい Library を取得して比較せよ」という警報であり、「このサブスクリプションは非互換だ」という判定ではない。

運用手順は、変化検知、前後スナップショット取得、import を含む差分計算、影響範囲の再生試験という順序になる。最初のシグナルだけで全停止すれば無関係な変更に振り回される。無視すれば import の盲点をそのまま残す。

modified 通知だけでは切り替えは原子的にならない

subscription-modified が到着した時、旧スキーマで符号化された通知がキューに残っている可能性がある。並列 worker がイベントを見る順番も一致しない。メタデータだけ新版に更新され、データ処理が旧 binding のまま進むこともある。

そのため、旧工件で処理した最後の位置、ライフサイクル通知の位置、新工件で受理した最初の位置を記録する。境界が曖昧なデータは隔離し、正しいスキーマを読み込んでから再生する。判断に使った出力は、元データだけでなくスキーマとデコーダーの版へ戻れる必要がある。

subscription-terminated も公開側の終了判断を証明するだけだ。古いキューが空になったこと、キャッシュ値による処理が止まったこと、派生ジョブが取消されたことは別に確認する。終了イベントをローカルな停止・隔離・承認手続きへ接続しなければ、古い意味が後段で生き続ける。

yang-push-module-revision-supported capability は対応機能の広告である。クライアントが手順を選ぶ材料にはなるが、実際の遷移で正しく通知する証拠ではない。更新、再起動、欠落、重複、順序入れ替えを含む試験が必要だ。

配信、解釈、権限、効果を一つの緑ランプにしない

証拠は順に積み上がる。公開側がどの Library を持つか。制約をどの状態に対して受け入れたか。どの版を lifecycle 通知で示したか。通知がどの順序で届いたか。受信側がどのスキーマを読み込み、どのコードで変換したか。ローカルポリシーが何を判断し、誰が実行を許可され、操作が試みられ、効果が観測されたか。

前の層は後ろの権限を借りられない。流れ続けることは正しい解釈を証明しない。正しい解釈は操作権限を与えない。権限は実行成功を保証しない。変化の観測は、その原因まで自動的に決めない。

Reality Layers を維持すると、障害の所在が明確になる。content-id が変わっても依存差分に影響がなければ、無害な変化として閉じられる。revision が同じなのに判断が変われば、消費側を調べる。技術的には正しい操作でも無権限なら、問題はアクセス統制にある。

共通 ID と時刻で各受領証を結ぶことは有効だ。しかし結論は統合しない。各層が観測した範囲と不確かさを残すことが、後付けの物語ではない監査記録を作る。

版制約の変更は高権限なポリシー変更である

revision や version 条件を変更できる主体は、受け入れる意味の範囲を変更できる。古いモデルへ固定し、次回再起動で終了を起こし、あるいは試験していない範囲まで許可できる。表示設定と同じ扱いにはできない。

NETCONF や RESTCONF の安全なトランスポートと相互認証は引き続き必要で、NACM は設定・状態へのアクセスを制限する。監査には主体、方法、変更前後、対象サブスクリプション、Library 状態、承認理由を残す。可用性を回復する自動処理が、自分で条件を緩めて緑に戻す設計は避ける。

サブスクリプション作成権限と、そのデータからネットワーク操作を行う権限も分ける。データが意思決定へ入る地点で、別のポリシーと認可が必要である。

実装状況は相互運用試験の代わりではない

ドラフトには Huawei VRP、6WIND VSR、Cisco IOS XR について、著者が報告した異なる部分実装が記載されている。実現可能性を議論する材料にはなるが、独立検証や製品間の相互運用を証明しない。

導入前には、未対応 revision、未対応 version、矛盾条件、互換版選択、再起動終了、稼働中変更、直接モジュール変更、import のみの変更、無関係な Library 変更を実機 build で試す。さらに lifecycle 通知の欠落、重複、順序逆転と rollback を加える。

ワイヤ記録、受信側の永続状態、再生結果を build に結び付ける。実装一覧に複数名が載ることと、同じ遷移について独立実装が一致することは別である。

更新を「止まらなかった」で完了させない

更新前に旧 Library、モジュール、生成 binding、デコーダーイメージ、再生コーパスを保存する。候補集合を import 込みで比較し、受理と拒否の両方を試す。戻すべき工件を残さない更新は、版情報があっても可逆ではない。

切り替え中は lifecycle イベントとデータ位置を記録し、content-id が変われば Library を取得する。高影響な処理はローカル再生が通るまで止める。制約を満たせない場合は理由付きで失敗し、暗黙の代替をしない。

切り替え後は、件数だけでなくデコード結果、変換、判断、操作、効果を比較する。旧キューとキャッシュを確認し、公開側と受信側を同時に戻せるか試す。成功条件はサブスクリプションの生存ではなく、必要な意味の連続性が証明されたことだ。

このドラフトは、長寿命サブスクリプションの足元を見えるようにする。見えた変化をどう診断し、誰が受け入れ、どの行動を許すかは運用側の責任である。配信の連続性に、それ以外の証明を代弁させてはならない。

出典