Summary

  • draft-ietf-netconf-yang-notifications-versioning-14 は、YANG-Push購読をモジュール改訂または互換なセマンティック版で制約し、購読開始・変更通知へモジュール文脈を加える。
  • 改訂、任意のversion、yang-library-content-id は発行側のスキーマ文脈を示す。飛行中の記録、受信側デコーダ、保存変換、下流モデルが同じ境界で切り替わったことは証明しない。
  • Daniel Kadeは、通知、前後の厳密なモジュール集合、旧版で最後に解釈した記録、新版で最初に解釈した記録、キューと再送、試験、下流停止、責任者、終結を結ぶテレメトリ・スキーマ引継ぎ記録を提案する。IETF要件ではない。

一つの変更に複数の境界がある

保守予定には「02:00切替」と書ける。しかし運用では、装置が新しいライブラリを有効にした時刻、通知のeventTime、受信時刻、デコーダ配備時刻、永続化時刻、制御利用の再開時刻が別々に存在する。

どの時刻も正しい。ただし、どの命題について正しいのかが違う。

発行装置の時計は収集器のキューを支配しない。通知の受信はワーカープロセスが正しいデコーダを選んだ証拠ではない。保存成功は、アラート式や学習済みモデルが新しい意味に適合したことを示さない。運用画面が一つの「完了」に畳むと、その画面が暗黙に全層の決定者になる。

必要なのは唯一の時刻を探すことではなく、複数の境界を証拠で接続することである。

第14版が埋める穴

現行のYANG-Push受信側は、購読状態変更通知を得た後、参照モジュールの意味が変化したか確かめるため発行側のietf-yang-libraryを問い合わせる必要がある。通知と照会が離れていれば、遅延が生じ、照会時にはライブラリがさらに更新されている可能性もある。

提案中のietf-yang-push-revisionは、モジュール名と特定のrevisionまたはsemantic versionを購読条件に加える。サーバが要求を支援しなければRPCエラーを返す。設定済み購読の要求とYANGライブラリが一致しなくなれば、発行側は通知を送ってはならない。

さらにsubscription-startedとsubscription-modifiedへ、関連モジュール名、revision、存在する場合のversion、任意のyang-library-content-idを加える。受信側は購読IDが同じだから意味も同じだと推測せずに済む。能力モデルから拡張対応も発見できる。

これは小さくない進歩である。受信側は受け入れられないスキーマを先に拒み、稼働中の変化を発見できる。ただし仕様は、収集器のソフトウェアや下流業務まで一斉に切り替える分散トランザクションではない。

content IDの役割を広げない

YANGライブラリのcontent IDは、そのサーバにおける現在のライブラリ情報を表す実装依存の識別子である。値が変われば一つ以上のモジュールが変わったと分かるが、購読フィルタに関係するモジュールとは限らない。

また、収集器が使った正確なモジュールバイト列の共通ハッシュとは定義されていない。運用者は、取得したモジュール、import、feature、deviationを含む集合に独自の指紋を作れる。その指紋とサーバのcontent IDは、由来と範囲の異なる証拠として並べて保持すべきである。

通知のmodule-version一覧は対象を絞る。それでも受信側が同じ依存集合を解決したか、正しいデコーダをロードしたか、保存列の変換を更新したかは別問題だ。同名フィールドが構文上読めても、単位や存在条件の解釈が変われば判断は変質する。

識別子は参照点であり、利用結果の試験ではない。

通知はキューのフェンスではない

旧スキーマでAとBが生成され、Cが変更通知、新スキーマでDが生成されたとする。論理順はA-B-C-Dでも、制御通知とデータが異なる経路を通れば受信順はA-C-B-Dになり得る。replayでBがDの後に届くこともある。旧デコーダのワーカーがBを処理中に、新ワーカーがDを先に保存する場合もある。

Cが認証され、正しい時刻を持っていても、それだけでBを分類できない。輸送順序、キュー、ワーカー割当、デコード結果を観測する必要がある。

この全体をIETF拡張へ詰め込む必要はない。狭い仕様は実装しやすく、責任境界も明確である。問題は、利用者が仕様の外側を未解決のまま残すことではなく、通知一件を使って外側まで解決済みと宣言することだ。

「互換」は利用者ごとに検証する

従来のYANG revisionは互換性を保つことが期待される。YANG Semantic Versioningは非後方互換変更も明示できる。モジュール選択と購読方針に有効な情報である。

しかし互換とされた追加でも、特定のパーサの不具合を踏むことがある。featureやdeviationが試験環境と違えば実際の木も違う。新しいノードを下流モデルが無視することで、構文エラーなしに意味だけ失われる可能性もある。

変更作者の分類、購読方針の受理、消費者固有の試験を同じ「互換」で表してはならない。それぞれに判断者と証拠がある。

不一致による停止を正しく読む

設定済み購読のrevision/version条件がYANGライブラリと一致しなければ通知を送らない、という規則は重要だ。要求外の意味を持つデータを黙って流し続けないからである。

ただし受信側から見た無通信は、on-change対象に変化がない、輸送障害、収集器停止、権限変更、空のフィルタとも同じ姿を取る。最後の値を「安定」と表示し続ければ保護機構を無効にする。すべてをスキーマ事故と呼べば誤警報になる。

引継ぎ記録は、有効だった到着期待、停止条件を観測した主体、他原因との区別、再開承認を残すべきだ。原因が決まらなければ、高い影響を持つ利用だけを止め、空白へ都合のよい意味を与えない。

最小の引継ぎ記録

別記録はテレメトリ本体を複製しなくてよい。次を参照で結ぶ。

  • 発行者、購読ID、正確なXPath/サブツリー選択、要求revision/version；
  • 前後のサーバcontent IDと、それとは別の正確なモジュール集合指紋；
  • 認証済み通知のハッシュ、イベント時刻、受信時刻、処理時刻；
  • 旧集合で正しくデコードできた最後の記録と、新集合での最初の記録；
  • sequence、replay、resyncの証拠、待機・欠落・隔離・再処理区間；
  • デコーダと保存マッパーのビルド、試験入力、結果、変更ノードの扱い；
  • 停止、再計算、例外承認したアラート、制御、報告、モデル；
  • 決定責任者、残る不確実性、ロールバック先、終結証拠。

ここでの「最後」「最初」は、収集器が証明できる境界である。発行側の真の生成境界と同じとは限らない。その差を閉じる輸送証拠がなければ、差そのものを記録する。

安全な通信と正しい解釈

第14版はversion方針の書込みノードを機微なものとして扱い、安全な輸送、相互認証、NACMによる権限制御を求める。無権限の変更は配信を止め、予想外の文脈を押しつけ得る。

認証は参加者とメッセージ完全性を支える。キュー排出、デコーダ選択、業務ルールの妥当性までは証明しない。安全層の強さを、主張していない運用結果へ転用してはならない。

成熟した運用は変更通知を、範囲を定めた停止の開始信号にする。正確な集合を取得して指紋化し、fixtureでデコーダを試し、キューとreplayを照合し、前後の投影を比較したうえで利用ごとに解除する。フィルタ外の変更なら短く閉じられる。自動制御入力の意味が変わるなら、より強い証拠が要る。

通知は変化を知らせる。引継ぎ記録は、再開という決定を説明可能にする。

情報源