要約
- 9月4日のpull request 42の統合により、CATSメトリクス定義11版には観測時刻と有効期間の任意フィールド、運用上の考慮事項が加わった。これは作業部会Internet-Draftであり、RFCではない。
- 関数識別子を各メトリクスへ入れない判断は、8月の公開議論で明示された。複数ベンダーは起動前にオフラインで関数を合意し、実行時の動的調整を避ける。
- 11版はその合意を正式な設定マニフェストにまとめ、初期化時に同期して版管理するよう求める。稼働中は、スコアが共通関数を使い完全に比較可能だと仮定する。
- ところがフィールド一覧には、稼働中のマニフェスト版、ダイジェスト、エポックがない。正しく署名され新鮮な値でも、異なる尺度に基づく可能性を判別できない。
- 必要なのは関数の再交渉ではない。採用前に同一マニフェストを確認し、不一致時の動作を決め、判断と版を結ぶレシートを残すことだ。
「軽い実行系」を選んだ経緯
今回の変更点は、単なるフィールド追加ではない。pull request 42は9月4日に統合され、merge commitが固定された11版へ反映された。DatatrackerではCATS作業部会の有効な文書で、IESG状態は「I-D Exists」のままだ。標準化が完了したわけでも、導入実績を示すものでもない。
CATSは、ネットワークと計算資源の情報を使って要求をサービスインスタンスへ振り分ける。遅延、CPU利用率、利用可能メモリといった生値は単位も範囲も違う。正規化で共通尺度へ移し、集約でレベル1の分類別スコアやレベル2の総合スコアを作る。最終値が同じ7でも、上限、曲線のパラメータ、重み、大小の向きが違えば意味は同じにならない。
11版は、複数ベンダーが導入前にスコア範囲、正規化手法とパラメータ、集約式と重み、比較方向を合意するよう記す。結果は正式な設定マニフェストへまとめ、判断にメトリクスを使う各コンポーネントへ初期化時にオフライン同期し、版管理する。
稼働後については、さらに踏み込む。コンポーネントは、受け取ったスコアが合意済み関数で処理され、完全に比較できると仮定しなければならない。動的な交渉は不要だ。この単純化は合理的だが、共通設定が本当に配備されたかという一点へ信頼を集中させる。
Function欄を落としたのは意図的だった
8月の議論では、別案も具体化していた。pull request 41は、各値に適用関数、観測時刻、有効期間を持たせ、固定パラメータまで結び付けた関数登録簿を提案した。受信側が「状態が違う」「算出法が違う」「期限が切れた」を区別するためだった。
8月25日、共同著者はメーリングリストで方針を説明した。関数欄は毎回の報告に入れず、異なるベンダーの実装詳細は初期化時に帯域外で合意する。C-PSが関数IDを解析し、稼働中にアルゴリズムを変える設計は複雑すぎる。一方、観測時刻と有効期間は任意フィールドとして採用できる。
提案者もこの切り分けに同意した。枠組みはメッセージ単位の再交渉を想定していないため、起動時に一度確定するほうが強い。11版に入ったのはObservation_TimeとValidity_Intervalで、関数識別子ではない。PR 41には、PR 42が二つの任意欄を取り込んだとのコメントがあり、調査時点でPR 41は開いたままだった。
したがって、問題を「著者が識別子を忘れた」と説明すべきではない。複雑さを抑える場所を選んだのである。残る問いは、帯域外の合意が現在も全機器で一致していると、何によって証明するかだ。
リポジトリの最新版は稼働状態ではない
版管理されたファイルが一つでも、実行中のコピーが一つとは限らない。セレクターとベンダーAの生成側がM1に残り、ベンダーBだけM2へ移ったとする。M2では正規化上限か集約重みが変わった。両者がレベル2の7を送る。署名は正しく、発行者は許可され、時刻も新しい。それでも二つの7は同じ判断材料ではない。
これは仮想例であり、障害や実装を告発するものではない。ただし、草案の防御策では排除されない。Sourceは直接測定、推定、集約、正規化を区別する。Observation_Timeはいつ観測したか、Validity_Intervalはいつまで使えるかを示す。署名は誰がバイト列を結び付けたかを検証する。どれもM1とM2を区別しない。
統合前のレビューには、そのままの警告が残っている。PR 42のレビューコメントは、分散システムでオフライン同期が常に成功するとは仮定できないと述べ、失敗または不完全な同期の検出と報告を提案した。統合版は版管理マニフェストの文を残したが、その追加文は採らなかった。これは一人のレビューであって作業部会の合意ではない。ただ、失敗経路が事前に認識されていた証拠ではある。
OPSDIRによる10版の早期レビューも「Has issues」とし、ベンダー横断の比較、ポリシー識別子、校正、障害管理、運用モデル、移行の説明を求めていた。11版はその多くへ答えた。更新頻度を抑え、状態イベント時の追加通知を認め、欠落や鮮度失敗時には直近の良好値、優先度低下、除外、ネットワーク情報だけへのフォールバックを提示した。鮮度、部品障害、スコア異常の警報も推奨する。
しかしM2の値は異常とは限らない。M1から見ても自然な範囲に収まり得る。古い設定を持つ機器も健康に動ける。「直近の良好値」がどのマニフェストで良好だったか残らなければ、フォールバックが意味のずれを延命する。
合意内容ではなく合意の同一性を運ぶ
修正は小さくできる。メッセージごとに曲線や重みを配布し、セレクターが再計算する必要はない。正規のマニフェストIDとダイジェスト、管理ドメイン、対象コンポーネント、版または有効化エポック、発効時刻、同期完了状態だけを共有すればよい。
生成側とセレクターは、それぞれ現在のダイジェストを証明する。その値はメトリクスに添付してもよいし、認証済みセッションへ結び付けても、管理面で事前照合してもよい。重要なのは配置ではない。後から一つの選択について、計算と解釈が同じマニフェストの下で行われたと結合できることだ。
不一致時の扱いはローカルポリシーに残せる。値を拒否する、意味が見えるレベル1へ戻す、ネットワーク情報だけを使う、更新完了まで判断を留保する。レシートには生成側、セレクター、スコア、時刻、両方のダイジェスト、フォールバック、警報、判断、復旧条件を残す。秘密の重みや閾値を公開する必要はない。
現行CATS frameworkは一つの管理ドメイン内で共通関数を要求する。権限の数が少ないことは有利だが、更新漏れを消すわけではない。RFC 8911が別分野で示す固定パラメータ付きメトリクス識別は、採用義務ではなく「同じものを比べたと証明する」ための参考になる。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加