要約

  • NETCONF の revision 18 は、XPath 条件の評価結果に基づき YANG-Push の周期を切り替える実験的な仕組みを定義する。
  • 条件を調べる eval-interval と、更新を送る period は別であり、条件成立と次のデータ配信は同時とは限らない。
  • adaptive-period-update は対象受信者について破棄もフィルターもできないが、replay buffer に格納できない。
  • 切替中に不在だった受信者は、復帰後の高密度なデータを取得できても、切替理由の状態通知を標準の再生経路から回収できない。
  • 文書は Experimental を意図する Internet-Draft で RFC Editor queue にある。RFC、運用実績、相互接続性の証明ではない。

強いライブ通知が残さないもの

通常、「落とせない通知」は監査にも残るように聞こえる。しかし revision 18 の規則は、現在の購読セッションに対する制御を扱う。周期が変われば、影響を受ける受信者に状態変更を知らせなければならない。受信者側のフィルターで消すことも、低優先度データとして捨てることもできない。

同じ段落が、replay buffer への保存を禁じる。これは設計上の明示的な境界である。通常データの再生と、ライブ購読状態の履歴は同じ契約ではない。

切替前に収集器が切断し、切替後に復帰した場合を考える。再生要求は内容レコードを返し得る。現在の周期も観察できる。それでも「どの条件が、いつ、どの値で周期を変えたか」は、その状態通知だけでは復元できない。推定と証明を分ける必要がある。

評価時計と配信時計

eval-expression は対象データノードに対する XPath 1.0 条件である。eval-interval はその条件を調べる頻度を表す。省略時には、サーバーが検出可能な最短間隔を選ぶ。その値は実装依存で、CPU やメモリーによって動的に変わり得る。

一方、データの配信は period と anchor-time の境界に従う。値が閾値を越えた時刻、次に評価された時刻、周期を切り替えた時刻、次のレコードが出た時刻は別である。

したがって、高速周期への移行は「全ての過渡変化を見た」という意味ではない。離散評価の間に生じて戻った変化は、切替通知からは復元できない。period-update-time は切替時刻を示せても、センサーの連続した履歴にはならない。

XPath の受理は運用判断の受理ではない

複数条件は相互排他的でなければならない。対象ノードが削除されれば false と評価され、非ブール値は XPath の boolean 関数で変換される。サーバーは構文、短すぎる評価間隔、条件競合、未対応周期を明示的なエラーで拒否できる。

このエラー契約は曖昧な失敗を減らす。しかし、要求の成功が保証するのは、サーバーがその設定を受け入れたことまでである。閾値が適切か、負荷時にも同じ頻度で評価されるか、受信者が増加分を処理できるかは別の証拠を要する。

数値にも注意が必要だ。XPath 1.0 は IEEE 754 の倍精度を使い、一部の int64、uint64、decimal64 を正確に表せない。草案が同じ型、少数のノード、定数閾値を推奨するのは、単なる書式上の好みではない。

満足した値は完全性の証明ではない

切替通知には satisfied-criteria-data を含められる。条件を満たしたインスタンスと値を anydata で示し、トラブルシュートに役立てる項目である。

それでも任意項目であり、評価間に存在した全ての値を表さない。スキーマ世代、名前空間、型、実効評価周期を失えば、後の分析者が同じ判定を再現できるとは限らない。

最小の外部レシートは、式のハッシュ、名前空間、対象、実効評価周期、観測値、旧新周期、通知宛先、最初の新周期レコードを結ぶべきだ。これは BTW の運用提案であり、草案が既に永続台帳を定義したという主張ではない。

速い流れが受信者を圧迫する

静かな時間には通信を減らし、変化時には密度を上げる。この目的は明確である。しかし短周期はサーバーの評価・符号化と、ネットワーク、収集器のバッファー、保存、分析を同時に増やす。

Experimental の検証項目には、高頻度変化での安定性、規模、サーバー資源、受信者の処理、突発的な更新量、通信削減が明記される。また短時間に多数の切替通知が出る状態を、発振または不安定な式の重要な兆候として挙げる。

兆候は原因ではない。ノイズの多い値、ヒステリシスのない閾値、実際の障害、資源圧迫で変わる評価間隔は似た波形を作る。通知数だけで不可逆な制御を行うべきではない。

RFC Editor queue の意味を限定する

Datatracker は revision 18 を RFC Editor queue に置き、Experimental を予定する。アーカイブされた本文はなお Internet-Draft で、RFC 番号を持たない。編集工程の進展と、実験結果は同義ではない。

実装状況には、寄稿者が報告した Wi-Fi テレメトリーのプロトタイプが一件ある。本文は、その情報が独立検証されず、IETF の承認でもないと注意する。running code の報告は価値があるが、回復、全 XPath 能力、他実装との相互運用を自動的に証明しない。