有効なYANGスケジュールと古くなった権限

Summary

RFC 9922は、日時、期間、繰り返し、検証、状態を表す再利用可能なYANGの型とグルーピングを標準化した。一方、起動される行為の中身と競合解決は明示的に対象外であり、「enabled」という状態だけでは現在の決定権者を特定できない。
Daniel Kadeは、スケジュールの版とハッシュ、行為、対象、組織上のスポンサー、現行ポリシー、実行主体、時刻、結果を実行回ごとに結ぶ「オカレンス権限レシート」を提案する。これは運用上の編集提案であり、RFCの要件でも実在障害の主張でもない。

将来に届くのは命令であって、決定の文脈ではない

スケジュールは、決める時刻と作用する時刻を切り離す装置だ。混雑を避けた保守、将来の資源予約、定期観測は、この切り離しがあるから自動化できる。毎回人が同じ判断を繰り返すなら、予定実行の利点は薄れる。

ただし、保存された規則と組織の権限は同じ速度では変化しない。担当チームが再編されても、繰り返し式は壊れない。サービスアカウントが移行期間中に残っていても、次回時刻は計算できる。対象の重要度が上がっても、期間の構文は正しい。

そのため、運用画面には複数の「正常」が並び得る。開始時刻は許容範囲内、スケジュールは有効、最新版、競合なし、時計も同期済み。しかし、それらを足しても「現在の組織がこの作用を認めた」という命題にはならない。

侵入者も不具合も要らない。過去の正当な指示を忠実に保つシステムと、役割を正当に変更する組織だけで、このずれは生じる。問うべきは、スケジューラーが従ったかではなく、今回の実行を誰の現行判断として扱ったかである。

RFC 9922のvalidityは時間の境界である

RFC 9922は2026年3月に公開されたIETF Standards Track文書で、公開レビューとIESGの承認を経たIETFの合意文書である。ietf-scheduleモジュールは、イベント、ポリシー、サービス、資源を日時に基づいて予定するための共通型とグルーピングを定義する。単発、期間、単純な反復からiCalendarに近い反復までを扱う。

文書は射程を明確にしている。スケジュールがどんな行為を起動するかは仮定せず、スケジュール間の競合検出と解決も対象外とする。共通モジュール自体には書き込み可能ノード、運用状態ノード、RPCがなく、利用側モジュールがグルーピングを組み込み、必要に応じて拡張する。

これは不足ではなく再利用性の条件だ。アラーム、OAM試験、資源予約、設定削除を、同じ承認制度で縛るべきではない。時間と具体的な作用を結んだ側が、その作用に合う統制を持つ必要がある。

generic-schedule-paramsのvalidityは、スケジュールを開始できる最終日時を意味する。そこより後のオカレンスは実行されない。開始の上下限、終了上限、破棄時の処理も、要求を時間上検証するために働く。

ここで有効なのは時刻条件だ。承認機関、作成者の現在の職責、実行時のポリシー版、対象変更後の再承認までは含まれない。時間上まだ有効であることと、制度上まだ許されることは別の証拠を要する。

NACMが守る要求と、後日の実行主体

RFC 8341のNACMは、NETCONFとRESTCONFにおける操作とデータへのアクセスを制御する。認証済みセッションはユーザー名とグループに結び付けられ、サーバーはメッセージ処理開始時に有効な規則を使う。予定の作成、変更、削除や、利用側モジュールが公開するactionを守るうえで欠かせない。

ゆえに、問題を「YANGにはアクセス制御がない」と表現するのは誤りだ。問題は、作成要求と数か月後のオカレンスを同じ主体の同じ判断とみなしてよいかである。

RFC 8341はユーザーセッションから始まる要求を中心に扱い、サーバー主導の一部アクセスは同じユーザー要求として強制されないと説明する。これは全スケジューラーの実装を決める記述ではない。オカレンスを新しいactionとして評価する実装も、サービス主体を使う実装も、期間限定の組織権限を使う実装も可能だ。

定期バックアップを最初の担当者の異動で止める必要はない。一方、鍵、経路、希少資源、高リスク設定に触れる予定は、対象や条件が変われば新たな判断を必要とし得る。重要なのは、継続規則を偶然に任せないことだ。

作成者、現在のサービス責任者、技術的な実行主体、結果を承認する機関も分けるべきである。一つの古いユーザー名にまとめると、継続も失効も不正確になる。

正しい時計は許可を発行しない

RFC 9922は、信頼できる時刻同期がスケジュールの前提だと警告する。時刻がずれれば誤った間隔で起動し、高頻度の反復は異常を通常の活動に埋めたり、処理資源を占有したりする。各回の起動時刻と行為結果を詳しく記録しなければ、後から追跡しにくい。

RFC 3339は日時表現を定め、RFC 7317はYANG管理システムのタイムゾーンとNTP設定を扱う。RFC 8915のNetwork Time Securityは、時刻同期相手の識別、パケット認証、リプレイ検出、要求と応答の対応を強化する。

これらは「2時だった」という証拠を強くする。「2時にこの行為をしてよかった」という証拠ではない。認証済みの時計は、権限を失った命令を正確な時刻に起動できる。逆に、正当な行為も時計の誤りで失敗し得る。

監査記録では、時刻源、予定時刻、観測時刻、不確かさを一方に、承認根拠、現行ポリシー、実行主体、許可・拒否を他方に置く必要がある。一つの緑色に畳むと、どちらの境界が破れたか分からない。

将来の資源予約は遅延作用を可視化する

RFC 8413は、将来必要になるトラフィックエンジニアリング資源を事前に予約する枠組みを説明する。LSPの経路と容量を先に確保し、予定時間になって初めて設定する。将来LSPと予約を相関させ、なぜ資源を押さえたか、キャンセル時にどう解放するか、プリエンプションをどう扱うかを分かるようにする。運用者ポリシーは引き続き重要だ。

RFC 8934は、ステートフルPCEでLSPを作成、変更、起動、削除するPCEP拡張を定義する。予定LSPのデータベースが将来状態を保持し、開始時にPCCが設定し、期限に達すれば属性に従って削除する。要求、計算、同期、実際の作用は同時ではない。

これらのRFCは権限事故を報告していない。だが、プロトコル上の制約を満たすこと、資源が空いていること、組織がいま望んでいることが別の接点だと分かる。顧客要求が別系統でキャンセルされても、経路計算は成功し得る。利用可能性を決定権の代用にしてはならない。

オカレンス権限レシート

共通モジュールを改変する必要はない。スケジュールを重要な作用に結び付ける利用側で、実行回ごとの証拠を作ればよい。低リスクで同質な反復なら、暗号学的に範囲を限定した一つの決定で複数回を覆える。

レシートに必要なのは次の結合だ。

安定したスケジュールID、現行版、定義全体のハッシュ
反復インスタンス、予定時刻、観測された起動時刻
行為と対象のクラス、機密値への保護されたコミットメント
作成者と現在の組織スポンサー
作成時の承認根拠と実行時のポリシー・委任版
実行主体と現在のallow・deny結果
時刻源と必要な不確かさ
競合、優先順位、プリエンプション、ローカルポリシーの処理
意図状態のコミットメント、適用状態の観測、結果
失敗、キャンセル、意図的な非実行の理由
置換、失効、訂正へのリンク

人の承認を毎分要求する設計ではない。署名済みの権限リースは、行為クラス、対象集合、リスク上限、回数または期間を覆える。ただし、版、スポンサー、対象、ポリシー、競合条件、期待効果が変われば失効する。

公開レシートにユーザー名、トポロジー、設定値を載せる必要もない。組織上の役割、ポリシーID、ハッシュ、保管者、処理結果だけを見せ、詳細を保護証拠に置ける。

目標は「いつ動いたか」と同じ精度で「なぜ今回動かしてよかったか」に答えることである。

反論が実装の大きさを決める

第一の反論は継続性だ。担当者の休暇、退職、鍵交換で組織の予定が止まっては困る。そのとおりである。だから個人から持続的な組織スポンサーへの移管を明示し、履歴を残す。古いアカウントを黙って温存することとは違う。

第二は計算コストだ。高頻度処理で毎回複雑なポリシーを評価するのは重い。範囲と期間を限定した判断をキャッシュし、無効化条件を明示すればよい。作成時の許可を永久化する必要はない。

第三は重複だ。NACM、オーケストレーター、監査基盤がすでに材料を持つ場合、レシートはコピーではなく結合になる。権限のある第三者が、口頭説明なしに版、現行主体、オカレンス、結果をたどれるかが基準だ。

第四はモジュール性だ。RFC 9922が行為を知らないのは設計どおりである。したがって統制は利用側モジュールまたは運用監査層に置く。共通化を過失扱いせず、その境界で責任を明示する。

証拠の限界

ここで読んだのは標準文書であり、実運用の調査ではない。特定の事業者、ベンダー、製品が古い権限で予定を実行しているとは証明できない。侵害、障害、損失、違反も示していない。既存実装に所有者、サービス主体、再承認、十分なログがないとも言えない。

提案するレシートはIETF要件ではない。RFC 9922は明確な相互運用問題を解く合意済みStandards Track文書であり、作用固有の安全検討を利用側に委ねるのは妥当だ。

確実に言える範囲は狭い。RFC 9922の時間・運用語彙ではスケジュールが現行でも、結び付いた行為の制度的権限は別の事実である。権限を持続させるのか、移管するのか、再評価するのか、撤回するのかを記録しなければ、enabledという状態がモデル以上の約束に見えてしまう。

有効なYANGスケジュールは、実行権限が残る証拠ではない

なぜ重要か

Summary

将来に届くのは命令であって、決定の文脈ではない

RFC 9922のvalidityは時間の境界である

最新版にもスポンサーが見えないことがある

NACMが守る要求と、後日の実行主体

正しい時計は許可を発行しない

将来の資源予約は遅延作用を可視化する

オカレンス権限レシート

反論が実装の大きさを決める

証拠の限界

Sources

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説