要約

  • RFC 9922 は日付と時刻に基づくスケジュールのための共通 YANG 語彙を定める。反復の状態、last-occurrence、upcoming-occurrence はスケジュールの観測値であり、アクションの受領証ではない。
  • この RFC はスケジュールが起動するアクションの性質を仮定せず、競合の検出・解決も範囲外とする。認可、起動、実行、復旧、効果確認は別々のローカルな記録でなければならない。

監査会議で「今月も自動化済みです」と言いたくなる表示がある。カレンダーは有効、次の枠は計算済み、前回の発生も記録されている。だが、この三点から「自動化が変更を完了した」と進むと、スケジュールの記述を実行の証拠にすり替えることになる。

RFC 9922 はそのすり替えを許さない設計である。イベント、ポリシー、サービス、資源について、他の YANG モジュールが日付と時刻のスケジュールを表すための型と grouping を提供する。基本的な反復、UTC、タイムゾーン、期間リスト、iCalendar 由来の規則を共通化する。どのモジュールが何を行うかまでは決めない。共通の表現は時間を相互運用可能にするが、行為そのものを生まない。

そのフィールドが言うことだけを読む

schedule-status は状態、版、スケジュール種別、ホストのローカル時刻、最終更新、反復カウンタ、前回発生、次回発生、前回失敗発生、失敗カウンタを含み得る。これは便利な運用情報である。ただし、便利さは語られていない結果を補う許可ではない。

反復スケジュールでは、状態が有効の場合にだけ upcoming-occurrence を示せる。これは、そのホストが表現している規則から次の発生を計算したことを表す。実行担当が生きていること、時刻が来ても資源があること、呼出者が許可されること、対象が受理すること、意図した効果が残ることは表さない。last-occurrence は以前の予定発生を指し、last-failed-occurrence とは意識して分けられている。いずれにも操作 ID、対象の応答、補償、外部から観測した成果は入らない。

境界は名称だけではない。ietf-schedule モジュール自体は identity、型、grouping を定義するだけで、書込み可能なデータノード、読出し専用状態ノード、RPC を単独では持たない。経路を変え、設定を保存し、帯域を割り当て、鍵を回転させる装置ではない。これを使うモジュールが、スケジュールとアクションの関係、安全性、例外、競合をその領域で定義する必要がある。

RFC 9922 は、スケジュールが起動するアクションの性質を仮定しないと明記し、スケジュール競合の検出と解決を範囲外に置く。二つの要求が同じ時刻に重なった時に何を優先するか、緊急変更が通常の枠をどう越えるかは、共通モデルが黙って決めてよい問題ではない。損失と説明責任を負う場所で決めるべきローカルな選択である。

時刻の算出、認可、実行、効果は一つの証跡ではない

確かな変更記録には少なくとも四つの面が必要になる。第一は定義面で、規則、版、例外、時刻源、タイムゾーン、計算された発生を残す。第二は認可面で、誰がどの範囲を要求し、どのポリシーがいつ許可または拒否したかを残す。第三は実行面で、不変のアクション ID、対象、開始・終了、応答・エラー、ロールバックまたは補償を残す。第四は効果面で、スケジューラや実行応答とは別に、約束したサービスまたは資源状態が本当に成立したかを観測する。

これらはそれぞれ正しくてもつながらないことがある。時刻同期が悪ければ誤った間隔で発火する。スケジュールは有効のまま、呼出し worker は停止できる。ポリシーは予定どおり届いた要求を拒否できる。対象は要求を受け付けても、後段の検証が意図した状態を否定できる。RFC 9922 が不正確な時刻、過度に頻繁な反復、発火・アクション結果の詳細ログ不足を注意するのは、この切れ目が事故の説明不能につながるからである。

RFC 8413 の計画資源も近い教訓を示す。将来の LSP のために計算された資源状態は役立つが、要求時点の可用性は best effort にとどまり、運用者の方針は計算要求を拒否できる。後のインスタンス化とシグナリングも別工程である。これは RFC 9922 の実装ではないが、計画、方針、実現した状態を混同できない理由を具体化する。

管理アクセスの保護も別層である。RFC 9922 は YANG 管理に安全な転送と相互認証を求める。RFC 8341 の NACM は操作、データ、action、notification へのアクセスを分けて制御する。スケジュールを読める安全な接続は、予定アクションを行う権限ではない。許可されたプロトコル操作も、外部の結果証明ではない。

ここでの盧恒の基準は明快である。モデル、画面、状態ラベルは表現の層にある。時刻を正しく評価し、呼出し時に地域の方針を照会し、ID を持って対象に届き、応答と効果を検証する実行経路が運用上の現実に属する。薄い共通層を厚い完成報告に変えないことが、むしろその有用性を守る。

出典