要約

  • プライベート候補草案の第10版は、NETCONFセッションごとに独立した設定作業領域を設け、runningが変わった後のupdateをアトミックに扱う。commitは必ずrevert-on-conflictによる暗黙の更新を行うため、未解決の競合があれば処理は止まる。
  • その先の選択は損失を伴う。prefer-candidateはプライベート値を残し、後のcommitで稼働値を上書きする。prefer-runningは競合したプライベート編集を消す。NACMの権限や能力通知だけでは、そのサービスでどちらを選ぶ委任があったか分からない。
  • 必要なのは、ブランチの基点、競合集合、解決モード、失われる値、判断責任者、承認範囲、試験、confirmed commit、復旧先を結ぶコミット令状である。これはDaniel Kadeの提案であり、IETFの要件ではない。

隔離が成功した後に残る問い

RFC 6241のcandidate datastoreは、設定を有効化する前に一式を準備できる。そのcandidateは共有されるため、別セッションも内容を変更できる。あるクライアントが、自分では作っておらず確認もしていない変更まで一緒にcommitする余地がある。

ロックは混入を抑えるが、他の作業を止める。RFC 5717のpartial lockも、一回のcommitに一クライアントの編集だけが含まれることを保証しない。同じツリーに対する並行編集を解決できず、モデル間の依存関係を把握してロック範囲を決める必要もある。

draft-ietf-netconf-privcand-10は、この弱点に明確な境界を置く。2026年8月24日に公開され、NETCONFワーキンググループのWorking Group Last Callにある現行Internet-Draftで、Proposed Standardを目指している。まだRFCではなく、実装や導入の事実を示す文書でもない。

NETCONFでは、双方が能力を通知したセッション全体がプライベートモードになる。最初の対象操作でrunningのコピーが作られ、そのセッション専用のcandidateとなる。他のNETCONF設定セッションから編集は見えず、アクセスもできない。接続が閉じるか失われると、未commitの編集とともにcandidateも破棄される。

これにより、他人の仕掛かりを知らずに有効化する事故を避けやすくなる。全体ロックを常用せず、複数の準備を並行させられる。重要な改善である。ただしrunningは、プライベートブランチの作業中も動く。再び接続するとき、問題は所有権ではなく優先権になる。

ブランチが専用であることは、編集者を示す。サービスを支配する資格までは示さない。

競合は「今の値」だけの問題ではない

updateは、private candidateの土台を現在のrunningに置き換え、クライアントの変更を再適用する。処理はアトミックであり、途中まで混ざった状態を残さない。

草案が定義する競合には、意図の変化可能性が含まれる。準備期間にrunning側とcandidate側が同じ設定ノードを変更し、新しい開始点を見ていればクライアントが別の編集をした可能性がある場合だ。値、存在、ユーザー順序、presence container、leaf-list、leaf、YANGメタデータも対象になり得る。サーバーは追加検査を設け、transaction IDを利用してもよい。

競合はノードごとのin conflict状態として内部的に扱われる。印の付け方は仕様の範囲外で、子の印が祖先へ自動伝播するわけでもない。クライアントが意図を再評価できるよう、XPathと値を伴う位置情報が示されるべきだとされる。

ここに技術的な強さと制度的な限界が同居する。装置は衝突した場所を知っていても、稼働値が緊急対処なのか、candidateが承認済み移行なのか、一つのleafが共有サービス全体に及ぼす意味までは知らない。認証済みの二主体が、それぞれ正当だが時間や範囲の異なる委任で動くこともある。

競合検出は異議を残す。異議を裁く権限は作らない。

三つのモードは、誰の変更を失うかを決める

revert-on-conflictは必須で、既定のモードである。一つでも競合があればupdateは失敗し、マージは行われない。commitは、サーバーの自動更新に別の既定値があっても、必ずこのモードで暗黙のupdateを行う。失敗後、クライアントは編集、破棄、またはモードを明示した手動updateを選ばなければならない。この停止は、損失前に判断を差し込める貴重な境界だ。

prefer-candidateは競合したプライベート値をcandidateに残し、競合しないrunningの変化を取り込む。次のcommitでは、その値がrunningを上書きする。失われるのは、ブランチ作成後に稼働側へ入った意図である。

prefer-runningは、競合した稼働値をcandidateへ押し戻してプライベート編集を上書きする。他の編集は残るが、作者が準備した目的の一部が消える。

名称から正しさは導けない。candidateだから業務上新しいとは限らず、runningだから将来も守るべきとも限らない。稼働値が一時的な緊急措置である場合も、candidateが期限切れの計画である場合もある。データストア名は状態を記述するだけで、制度上の順位ではない。

草案は、runningの変更後にサーバーが自動updateを行い、そのために別のシステム解決モードを選ぶことも認める。既定以外なら通知が必要で、三モードをすべて実装しない場合は対応集合も通知する。動作は発見可能になる。しかし、なぜその装置群に採用したか、誰が損失を受け入れたか、いつまで有効かは残らない。

最終commit時には競合がなくても、以前の自動updateで一方の意図が既に消えているかもしれない。commitログだけでは、結果を有効化した主体は分かっても、結果を形作った選択の責任者は分からない。

NETCONFとRESTCONFでは承認を置く場所が違う

NETCONFのプライベートモードはセッション全体で交渉される。クライアントが要求してもサーバーが未対応なら、後方互換性のため無視するか、セッションを閉じることができる。新しい実装には閉じる方向が勧められている。クライアント設定だけを見て隔離済みと判断してはならない。

RESTCONFにはクライアント側の同等な能力通知がない。サーバーがprivate-candidate対応を知らせると、データリソースへの書き込みはリクエスト専用candidateを使い、自動commitされる。拡張を知らないクライアントが期待する即時反映を守るためであり、複数操作にまたがるNETCONFセッションの作業領域とは異なる。

したがって承認設計も異なる。NETCONFブランチは長く残り、その間に稼働状態、権限、保守時間帯が変わり得る。RESTCONFでは準備と有効化が一つの短い境界に圧縮される。共通用語を理由に同じ承認手順を貼り付けるべきではない。

アクセス許可は変更ごとの委任ではない

RFC 8341のNACMは、利用者と内容に応じてread、write、executeを制限できる。草案もupdateを慎重に扱うべき操作とし、不正アクセスが意図しないcandidate変更を招くと警告する。相互認証と安全な通信は前提である。

それでも、危険な競合はしばしば二つの正規主体の間で起きる。プラットフォーム用アカウントはinterface subtreeへ書けても、障害班の遮断措置を解除する委任はないかもしれない。広い権限を持つ技術者でも、共有依存を上書きする承認は別である。保守時間が切れた自動化は、資格情報だけなら依然として有効に見える。

NACMは「この主体がこの内容にこの操作を行えるか」を答える。変更統治は「この作業経路が、今、この値を別の有効な意図より優先できるか」を答える。前者を後者の代わりにすると、長期資格情報が恒久的な議決権になる。

RFC 9144を拡張する比較も証拠であって判断ではない。対応サーバーではprivate candidateをrunning、作成点、最後のupdate点と比較できる。差分の由来は明確になるが、サービス影響、依存関係の完全性、委任の妥当性は決められない。

コミット令状で判断を短く固定する

不足しているのは新しいprotocol datastoreではない。一回の競合解決に結び付き、前提が変われば失効するコミット令状である。

装置、datastore、セッションまたはリクエスト、認証主体、自動化所有者を最初に固定する。candidateの作成点、最終update点、安定したrunningのrevision識別子も記録する。基点がなければ、後日のdiffに意味のある出発点がない。

次に、正確なcandidate deltaとサーバーが返した全競合集合を保存する。ノード単位の印が影響を小さく見せる場合は、ローカル方針がサービスや祖先の文脈を足す。通知された既定値、対応モード、自動か明示か、実際に使ったモードを結ぶ。

損失を曖昧にしない。prefer-candidateなら上書き予定の稼働値、prefer-runningなら消えたプライベート編集、revert-on-conflictなら未解決状態と次の許可済み行動を列挙する。

NACM方針の版は権限面の証拠だが、承認の代用にはしない。人または自動化の判断責任者が理由、サービス範囲、保守時間、影響上限、有効期限を示す。比較結果、設定検証、代表的なサービス試験を添付する。

最後にconfirmed commitの有無とtimeout、必要なら永続識別子、監視すべきhealth signal、正確なrollback targetを指定する。完了時に結果と新しいrunningのfingerprintを残す。稼働状態、方針、時間帯、観測条件のどれかが変われば令状は失効する。

これはDaniel Kadeによる運用統治の提案であり、IETF要件でもNETCONF RPCでもYANGノードでもない。目的は処理を遅くすることではなく、有効な別意図を消す場面だけを、後から説明できる状態にすることだ。

戻れることと、選択が正しいことは別である

confirmed commitは重要な保護である。プライベート候補によるconfirmed commit中にクライアントセッションが切れた場合、runningは直ちに戻され、提案した変更も破棄される。制御経路の喪失を限定する実用的な仕組みだ。

しかしrollback可能性は、最初の優先判断を正当化しない。委任外の選択にも優れたrollbackはあり得る。正当な緊急判断に安全な復旧手段がなければ、実行を止めるべきであって、権限問題をなかったことにはできない。

discard-changesも「現在の本番へ戻る」とは限らない。candidateは作成点または最終update点のうち新しい方へ戻るが、その状態は現在のrunningと異なる可能性がある。

隔離は作者を守り、競合検出は異議を守り、rollbackは帰路を守る。セッションが消えた後も勝者の根拠を守れるのは、判断時点で作られた令状だけである。

情報源