要約

  • draft-ietf-opsawg-collected-data-manifest-14 はPlatform Manifestを収集データと共に送信・保存・移動するよう求める一方、Data Collection Manifestは非規範の例にとどまる。
  • 送信時刻、プラットフォームID、サブスクリプションIDを使い、値を当時のYANGモジュール、フィルター、起動条件、実周期へ結び付ける。
  • 結び付いた記録だけでは、欠落のないデータ列、信頼できる時計、改変のない保管、正しい意味、認可された判断、実際の効果は証明できない。

テレメトリの数字は単独では証言しない。インターフェースカウンターの 0 は、本当に値がゼロだったのかもしれない。しかし、プラットフォーム負荷、短すぎる観測周期、カウンターのリセット、輸送途中の欠落でも同じ表示になり得る。第14版 A Data Manifest for Contextualized Telemetry Data が狙うのは、数字だけを保存し、観測条件を捨ててしまう最初の失敗である。

提案する構造は具体的だ。規範的なPlatform Manifestは、ネットワーク内のプラットフォームID、ベンダーまたはPEN、ソフトウェアとOSの情報を保持し、YANG Libraryからモジュールの版、名前空間、機能、逸脱、スキーマ、データストアを示せる。別のData Collection Manifestはサブスクリプション状態を再利用し、ストリームまたはデータストア、フィルター、サブスクリプションID、受信先、周期式か変更時通知か、設定周期と現在周期を記録する。ただし設計時のスキーママウントがないため、この収集モデルは規範本文ではなく付録の例である。

current-period は小さなリーフだが意味は大きい。コントローラーが10秒周期を要求しても、過負荷のプラットフォームは20秒へ広げる場合がある。ドラフトは設定値だけでなく、現に使われる周期を読み取り専用で返す。分析者は疎な時系列を障害と早合点せず、収集条件の変化として検討できる。

保存方法も単なる資産台帳の書き出しではない。マニフェストはデータと同時に送信・保存され、別のデータベースへ動くときも付随し、ルーター更新やサブスクリプション変更のたびに更新されなければならない。つまりマニフェスト自体も時系列になる。後日データ点を調べるときは、送信時刻、送信元プラットフォームID、サブスクリプションIDを取り出し、その時刻より前で最新のプラットフォームと収集のマニフェストを選ぶ。

これは有用な結合である。しかし、履歴そのものの証明ではない。

まず送信元プラットフォームを確かめる必要がある。IDはネットワークの範囲で各時点に一意であればよく、機器交換後に同じIDが別のハードウェアを指すことも許される。ホスト名の早すぎる再利用や、収集装置がベンダー固有モジュールから文脈を組み立てる際の誤対応があれば、データベースは正しい形式で間違った機器を結べる。資産台帳の変更と時刻境界が別に必要だ。

次にスキーマの同一性がある。YANG Libraryはリーフの版、名前空間、機能、逸脱を特定できる。現在のDatatrackerは第14版についてYANG検証をエラー0件、警告0件と表示する。だがドラフト自身が限界を明記している。yang-catalog と ietf-system の少なくとも一方を支援するという要件はYANGスキーマでは表現できない。どちらも有効でないモジュールも検証を通り、そのマニフェストはID以外のプラットフォーム詳細を持たない。検証の緑表示はモデルについての証跡であり、実装の十分性や分析結果ではない。

収集範囲も独立している。フィルターは何が流れ得るかを決め、周期式と変更時通知では沈黙の意味が異なる。current-period は周期の変更を示せても、予定された標本がすべて生成・受信されたことは示さない。ドラフトはマニフェスト収集の信頼性がデータ収集と同じだと述べる。マニフェストも同じ仕組みで集めるデータだからだ。同じ経路の付随記録に、その経路が失った全てを独立に証言させることはできない。

時点検索には時計への信頼が要る。「タイムスタンプ以前の最新版」は、機器、収集装置、データベースが同じ順序を再現できる場合に限って正しい。時計のずれ、配送遅延、収集装置によるタイムスタンプ置換、マニフェスト更新の遅れは、結合を壊さずに誤った版を選ばせる。タイムスタンプは規則の入力であり、物理時刻の証明ではない。

同じ保存先にあることも保管連鎖を閉じない。NETCONFまたはRESTCONFの安全な転送、相互認証、NACMは通信とアクセスを守る。完全性と由来には別のCOSE署名案が参照されている。バッファー、変換、複製、保存の各段階には固有の受領記録が必要だ。最終的にデータとマニフェストの二行が揃っていても、その前に欠落、順序変更、置換がなかったとは限らない。

解釈はそこから始まる。正確なスキーマはリーフの定義を与えるが、カウンター幅、リセットと周回、単位、集約方法、ベンダーの不具合、その後の変換履歴は別だ。ドラフトは計算済み指標のデータ系譜を範囲外に置く。正しい文脈の値から、誤った比率や基準線を作ることはできてしまう。

判断と効果はさらに別の二記録である。定義されるノードは全て読み取り専用で、RPCもアクションもない。マニフェストは経路変更や帯域制限を認可しない。権限を持つ主体が用途ごとに判断し、実行系が命令の受領記録を返し、サービス境界で変化を測る必要がある。文脈は判断を監査可能にするが、判断権を取得しない。

標準化の状態も同じように読むべきだ。2026年9月10日時点で第14版は8月19日付のActive Internet-Draftであり、IESGへの公開提出後、Expert Reviewにある。目標状態はProposed Standardで、YANG検証はエラー0件、警告0件だった。これはRFC承認でも導入記録でもない。

このドラフトの価値は、「データが自ら全てを証明する」ことではない。データに文脈の受領記録を持たせることだ。送信元、スキーマ、範囲、時間、保管、解釈、判断、効果をそれぞれ保存し、互いに結合できるようにする。マニフェストは次の問いを明確にする。次の答えまで代行はしない。

出典