要約

  • draft-ietf-netmod-immutable-flag-14 は、サーバーが提供する immutable 注釈と、クライアントが明示的に指定する with-immutability を定義する。既存の動作を記述する仕組みであり、動作そのものを作らない。
  • 注釈はデータノードのインスタンスに属し、親から継承され、子で上書きされ得る。単独のパスや平坦化された一覧では制約の範囲を再現できない。
  • invalid-value は一つの要求が拒否された証拠である。ユーザーやプロトコルをまたぐ一貫性、将来の不変性、運用状態、復旧可能性、事業成果は別に確かめる必要がある。

管理画面に二つの記録が並ぶ。読み出し結果には immutable=true、続く書き込みには invalid-value。一見すると宣言と実行がそろい、「不変」が証明されたように見える。正確な結論はもっと狭い。その時点の、その認証済みセッションとパスについて、サーバーが制約を示し、異なる値を拒否したということだ。

第14版草案 は、この狭さを欠陥ではなく設計として扱う。フラグは prescriptive ではなく descriptive である。YANG ベースのサーバーが既に行っている system-provided configuration の扱いを機械可読にし、クライアントが失敗を事前に理解できるようにする。注釈は内部ポリシーを制定せず、実装を監査もしない。

Datatracker は2026年7月2日付の本文を、Standards Track を意図する NETMOD の active Internet-Draft として示す。RFC Editor に向かう状態や YANG validation は文書処理の記録であり、製品採用、相互接続試験、運用結果の記録ではない。

まず、何をどう尋ねたか

通常の応答に注釈は付かない。NETCONF では <get-data> に with-immutability を加え、RESTCONF では値を持たない同名の GET パラメーターを使う。対象は読み取り専用の <system>、<intended>、<operational> に限られる。別の datastore なら unknown-element、RESTCONF パラメーターに予期しない値があれば HTTP 400 と invalid-value が求められる。

機能の広告も独立した証拠だ。NETCONF は YANG Library に ietf-immutable-annotation があるかを見て、RESTCONF は専用 capability URI を見る。広告はサーバーが語彙を理解すると主張したことを示すが、全インスタンスの付与、継承、書き込み拒否が正しいことまでは示さない。

旧サーバーは未知のパラメーターを拒否することも無視することもある。したがって、注釈が見えないという事実は、capability、要求、datastore と一緒でなければ解釈できない。「印がない」ことを「すべて変更可能」と読み替えてはならない。

インスタンスの系譜を保存する

同じ list の二つの entry が別の状態を持てる。子に注釈がなければ親の値を継承し、注釈のない top-level は false から始まる。子孫は明示的に状態をリセットでき、その下で再び切り替えることもできる。

このため true の葉だけを収集すると、継承元を失う。親だけを保存すると、子にある mutable な例外を失う。RFC 7952 の制約により、list や leaf-list 全体には直接注釈できず、個々の entry は注釈できる。集合全体の不変性は親からの継承として決まる。

全体が immutable な list では、entry の追加、削除、ユーザー順序の変更ができない。ある一つの entry が immutable なら、原則としてその entry と子孫が制約され、兄弟まで同じとは限らない。サーバーの値と同じ値を running にコピーし、後でコピーを消しても、merged intended の値は動かない場合がある。

クライアントが送った immutable 注釈はサーバーが無視しなければならない。これはサーバーの報告であり、クライアントが自分の値に付けるロックではない。署名済み要求も、送信したバイト列の来歴を示すにとどまる。

拒否理由には順番がある

草案の NETCONF と RESTCONF の例は、対象パス、重大度、invalid-value、説明を返す。完全な応答を保存すれば、単なる赤いアイコンよりはるかに説明力がある。しかし、その応答は認証主体、操作、提案値、時刻に結び付く。

NACM がある場合、アクセス制御が先に判定される。権限のないユーザーは access-denied を受け取り、immutable の検査まで進まないことがある。ユーザーごとに違うエラーが出ても、属性がユーザー依存だとは限らない。

経路も同様だ。NETCONF の拒否は RESTCONF、ローカルコンソール、ベンダーツール、起動処理、アップグレード、サーバー内部処理を試していない。草案がいうプロトコル・ユーザー非依存性は、実装に対して検証すべき適合条件である。

サーバー自身は変えられる

immutable が制限するのは、主にクライアントが別の値を押し込むことだ。サーバーは引き続き、自身が提供する設定を作成、更新、削除する。ソフトウェア、ハードウェア、ライセンス、機能、資源の変化により、提供値や不変とみなす対象は変わり得る。

<system> を公開しないサーバーにも immutable な設定は存在し得る一方、すべての system configuration が immutable ではない。このテーマは system datastore の生成・マージ全般ではなく、注釈が表す権限境界に限定される。

RFC 8342 は intended と operational を区別する。同時刻の system、intended、operational で値とフラグが一致すれば、有用なスナップショットになる。しかし、アップグレード後の一致、資源の存続、パケット転送、サービス品質、復旧成功までは証明しない。

一つの判定を八つの記録へ戻す

必要なのは、要求と datastore、capability と実効 schema、親子関係を含む返却 subtree、認証済み編集と完全なエラー、関係する datastore と視点、サーバー側変更イベント、テレメトリーとサービス canary、実行済み復旧と成果である。それぞれを関連付けても、一つの緑色判定に潰してはならない。

閉じた一次資料は第14版と Datatracker の記録・履歴、RFC 7952、7950、8342、8525、8526、8527、6241、8040、8341、9907、system-configuration 20 である：https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html。

これらは提案された意味とプロトコル境界を示す。特定ベンダーの適合、普及率、障害回避、復旧、顧客成果は示さない。付録の実装一覧も草案中の主張であり、独立した相互運用報告ではない。