要約

  • draft-hi-ccamp-cmis-control-yang-04は2026年9月9日に公開された。I-D Existsの個人提出Internet-Draftであり、CCAMPのWG文書でも、RFCでも、導入済み標準でもない。
  • 新設のControl Handover節では、ページをremote-write-allowed-pagesに加えると遠隔側へ書き込み制御を委譲し、外すと委譲を撤回してホストNOSがローカル設定を再適用すると定める。
  • 同じ改訂は、複数段階のCMIS操作について原子性と相互排他を定義しないと明記する。撤回時に途中まで実行された処理には、遠隔側の終了とホスト側の再開を分ける共通のプロトコル状態がない。
  • Daniel Kadeは、撤回と自律運用の間にページ単位のローカルな静止状態機械を置くよう提案する。これはIETF要件ではなく、ローカル検証に必要な最小限の事実だけを扱う運用上の提案である。

許可リストが「誰が装置を動かすか」を決める

改訂04の固定テキストは2026年9月9日付である。Datatracker APIは現行版を04、失効予定を2027年3月13日、状態をActiveおよびI-D Existsとしている。RFC streamも担当Area Directorもない個人提出だ。表紙のIntended statusがStandards Trackであっても、CCAMP採択を意味しない。

対象は着脱可能なDigital Coherent Opticsトランシーバの管理である。CMISのメモリページには標準機能に加え、ベンダー独自の機能が置かれる。ホストのネットワークOSが抽象モデルで既知機能を扱う一方、遠隔の光コントローラや装置上の第三者アプリケーションは、NOSがまだ理解しない機能へ先に到達したい。ドラフトのYANGモジュールは、そのためのレジスタ単位の読み書き、action、RPC、監視経路を設ける。

改訂04は、この低水準アクセスの位置づけを明確にした。抽象モデルを置き換えるのではなく、ベンダー固有属性には恒久的な経路を、NOS未対応の標準機能には過渡的な経路を提供するという。導入も、ラボ、立ち上げ、トラブル対応から始め、本番では読み取りと監視を先行させ、検証済みのページと手順にだけ書き込みを開くよう勧める。

核心は新しいControl Handover節だ。ページをremote-write-allowed-pagesに登録すると、書き込み制御は遠隔システムへ移る。委譲中、ホストNOSはそのページのレジスタを自律的に変更してはならない。ただし送信器停止など安全のための介入は例外で、介入後には遠隔側へ通知することが望ましい。

ページをリストから外すと委譲は撤回される。ホストはローカル設定を強制し、遠隔側が変えた値を上書きするか、モデルに従って既定値へ戻さなければならない。撤回はガバナンス変更後に開始した操作へ効き、適用前の処理中書き込みは拒否することが推奨される。

これは単なる入口の開閉ではない。操作主体を決め、安全例外を設け、主体が戻るときの装置状態まで指示する規則である。

許可の時刻と物理状態の時刻は一致しない

「まだ適用されていない」書き込みなら拒否できる。では、一部だけ適用された処理はどうなるか。光学機能は、ページ選択、値の格納、起動という複数の手順を踏むことがある。一つの操作が複数ページにまたがる場合もある。途中の撤回では、未開始、完了、取消、結果不明を区別しなければならない。

改訂04はこの保証を掲げていない。Security Considerationsは、ホストNOSと遠隔システムの間で行う複数段階CMIS操作の原子性や相互排他を定義せず、調整は運用者の責任で範囲外だと明記する。

境界を正直に示した点は評価できる。ただし、許可の撤回を制御返還の完了証明に使うことはできない。許可リストは次の遠隔要求を止められるが、前の書き手が装置を変え終えたこと、途中状態を解消したこと、ホストが安全な順序で設定を戻したことまでは証明しない。許可は一点で変わっても、ハードウェア状態は区間をかけて収束する。

影響は抽象的ではない。出力光パワーや周波数を変えるレジスタは、他の稼働波長に干渉し得る。ホスト管理フラグとページ選択を含むLower Memoryへの遠隔書き込みは禁止される。ファームウェア更新を起動できるCDBページ9FhからAFhも、永続的侵害につながり得るため委譲してはならない。これらは重要な不変条件だが、許可された処理が途中で切れた場合の終点は別途必要だ。

読み取りにも最後の所有者がいる

CMISにはclear-on-readのレジスタがある。先に読んだ側がイベントを消費するため、遠隔側が読めばホストから見えなくなり、逆も起きる。改訂04は、委譲ページを双方が同時利用することを委譲設計の誤りと位置づけ、委譲中の読み取り責任を遠隔システムに置く。

返還では証拠の管理も移さなければならない。ホストが状態確認のつもりで未共有イベントを消してはならず、空の値を「何も起きなかった」と決めつけてもならない。最後に責任を持って読んだ主体、または証拠を保存できなかった事実が、移行状態に含まれるべきだ。

RFC 8341のNACMは、NETCONFとRESTCONFの利用者、操作、データノードを制限する。改訂04がページ単位の制御を加えたのは、RPCやactionの入力値、たとえば対象ページ番号に応じた制限をNACMでは表せないためだ。両者は補完関係にある。しかし、どちらも二人の書き手の間に完了バリアを作るものではない。

撤回の後に静止バリアを置く

解決策は中央トランザクション管理を増やすことではない。装置の管理域内に四つの通常状態と一つの例外経路を置けばよい。

REMOTE_ACTIVEでは、コントローラ、装置またはインターフェース、ページ集合、ガバナンス版を固定する。撤回するとQUIESCINGへ進み、新規の遠隔処理を拒否し、処理中の各操作を完了、取消、結果不明のいずれかに確定する。複数段階の処理には、個々の通信応答とは別に一つの終端結果が要る。

次のHOST_RECONCILINGで、ホストは宣言された順序に沿ってローカル設定を再適用する。clear-on-read証拠の扱いを確認し、対象機能に応じてページ選択、送信器、周波数、出力、リンク状態などのローカル安全条件を検証する。成功して初めてHOST_ACTIVEとなり、NOSの自律動作が戻る。

SAFETY_OVERRIDEは別の枝にする。差し迫った危険なら静止完了を待たず送信器を停止できる。その代わり、対象範囲を残し、可能なら遠隔側へ伝え、必ず整合化へ合流させる。緊急権限は通常の所有関係を中断できるが、履歴を消してはならない。

記録項目は少なくてよい。モジュールまたはドラフトの版とハッシュ、装置・インターフェース・ページ集合、現在の制御主体、ガバナンス版、切替時刻、移行状態、処理中操作の帰結、取得可能なら最後に受理した操作ID、ローカル設定版、clear-on-readの管理主体、安全介入、整合確認結果、担当者である。ベンダー固有値、非公開トポロジー、攻撃に使える詳細は管理域外へ出さない。

これはHeng LuのMinimum Initial Specificationの節度に沿う。共有安全と状態遷移に不可欠な決定規則だけを共通化し、ベンダーの意味論と運用方針はローカルに残す。The Policy Mirrorが示すように、自動処理の後にも規則、権限、結果を再構成できなければならない。この状態機械は私の提案であり、ドラフトの要件ではない。

実装欄はまだ記入されていない

改訂04は他にも現実的な制限を加えた。ページメモリを無制限・高頻度で読むと、遅くてホスト管理と共有される内部バスを飽和させ得る。そのため対象を絞った操作、フィルタ、取得量の上限、レート制限が推奨される。プラットフォームは運用者の設定より厳しい制限も課せるが、その制限を知らせる方法は将来改訂へ残された。

一方、新設のImplementation Statusは未記入の雛形だけで、試作、商用導入、対応範囲を示さない。IETF 126のCCAMP議事録には、運用者のフィードバック、実装依存性、抽象モデルとの重複、Experimentalが妥当かという参加者の質問が残る。これらはWGの決定ではない。

公開資料から、競合、障害、光干渉、ファームウェア侵害、製品不具合が起きたとは言えない。確認できるのは限定的だ。改訂04はページの制御権を渡し、取り戻す規則を作ったと同時に、複数段階操作の排他を運用者へ委ねた。本番で使うなら、遠隔の書き手が静止し、ホスト状態が再び有効になったことをローカルに検証できる境界が必要である。

情報源