要約

  • 第11版は、一つの QUIC 接続を一つの NETCONF セッションに、クライアント開始の双方向ストリームを設定 RPC に、サーバー開始の単方向ストリームを個別のサブスクリプションに対応させる。これは明確な転送境界であり、設定適用の証明ではない。
  • 結果を監査可能にするには、ALPN 選択、TLS アイデンティティ、NETCONF 主体、セッションとストリームの対応、メッセージ境界、RPC 相関、NACM 認可、データストア遷移、独立した運用効果を別々に記録する必要がある。

draft-ietf-netconf-over-quic-11 の重要性は、単に NETCONF の下に QUIC を置くことではない。混同されがちな境界を見える形にした点にある。一つの QUIC 接続には一つの NETCONF セッションが載る。設定 RPC と応答にはクライアント開始の双方向ストリームを使う。通知にはサーバー開始の単方向ストリームを使い、サブスクリプションごとに一本を割り当てる。

境界が鮮明になるほど、別の誤解も生まれる。順序付きストリーム、暗号化接続、認証済み証明書、成功応答を一つに束ね、「設定結果が証明された」と呼びたくなる。しかし、それぞれは異なる事実だ。ストリーム内の順序は転送の事実、NETCONF の区切りは構文の事実、証明書は本人性の事実、NACM は権限の事実、<ok/> はプロトコル取引の事実である。running、intended、operational も同じ状態ではない。さらに、トラフィックの変化は別の観測を要する。

第11版は2026年8月25日に提出された。IETF Datatracker は、NETCONF ワーキンググループの active Internet-Draft、Standards Track を意図した WG Document、IESG 状態 I-D Exists と表示している。履歴 は改訂日を記録し、本文 は作業中で2027年2月26日に失効すると明記する。RFC、実装、導入、相互運用、性能、採用の証拠ではない。

実際に選ばれたアプリケーションを残す

RFC 7301 は ALPN を定義する。第11版は noq で NETCONF over QUIC を選択し、UDP 831番を使う登録を要求している。ここで「要求」は「完了」と同義ではない。研究時点の IANA ALPN レジストリ に noq はない。

したがって、設定や文書に文字列があるだけでは登録もネゴシエーションも証明しない。接続ごとに、実際の ALPN、エンドポイント、ポート、QUIC パラメータ、時刻、ソフトウェア識別を結び付ける。この証拠はアプリケーション選択を示すが、実装が草案全体に適合することまでは示さない。

証明書から NETCONF ユーザーまでには二つの判断がある

RFC 8446 は TLS 1.3、RFC 9001 は QUIC での利用を定める。第11版は NETCONF over TLS のモデルを使う。RFC 7589 は証明書検証と、証明書アイデンティティから NETCONF ユーザー名への順序付きマッピングを規定し、RFC 9144 が TLS 1.3 向けに更新する。

証拠は少なくとも二つ必要だ。まず、その時点の信頼アンカー、失効状態、名前検証によって証明書を受け入れたこと。次に、どのマッピング規則がどのユーザー名を生成したかである。証明書が同じに見えても、信頼設定や規則順序が変われば主体は変わり得る。

そして本人性は権限ではない。RFC 8341 の NACM は、操作、データノード、通知ごとに別の認可を行う。相互 TLS の成功だけで、編集が許可されたとは言えない。

接続の終了をセッションの終了として扱う

一接続一セッションなら、接続 ID、NETCONF セッション ID、主体、ネゴシエーション値、開始・終了時刻、終了理由を一つの会話として閉じられる。接続内でストリームを増やしても第二の NETCONF セッションにはならない。

反対に、障害後の新しい接続は新しいセッションだ。応答を失ったコントローラーが RPC を再送しても、新しい転送層は旧サーバーが処理済みか知らない。新しい message-id も、新しい業務意図であることを保証しない。

第11版は early data の利用を禁じる。RFC 9001 が示すように、0-RTT には本質的なリプレイ保護がなく、アプリケーション処理が複数回起き得るためだ。ただし、0-RTT を閉じてもアプリケーション再試行は残る。安定した要求 ID、再試行の系譜、サーバー取引記録、冪等性の規則がなければ「一度だけ」は証明できない。

ストリームの方向とサブスクリプションを結ぶ

RFC 9000 の QUIC ストリームは順序付きバイト列である。設定 RPC はクライアント開始の双方向、通知はサーバー開始の単方向で運ばれる。サブスクリプションは双方向ストリーム上の RPC で始まり、受理後にサーバーが単方向ストリームを開く。一サブスクリプション一ストリームである。

監査では、接続、セッション、ストリーム ID、開始側、方向、RPC の message-id またはサブスクリプション ID、時刻を一組として残せる。しかし、対応表は自動ではない。草案は両端がサブスクリプションとストリームの関係を追跡すべきだとし、その実装を範囲外に置く。ストリーム番号だけを持ち、サブスクリプション番号を失った記録は、通知の来歴として不完全だ。

単一ストリームの順序を全体順序へ拡張しない

QUIC が保証するのは同じストリーム内のバイト順序である。別ストリーム間の順序はない。RPC と通知が異なるストリームにあれば、受信順から因果関係を作ってはいけない。

アプリケーションには QUIC STREAM フレームの境界も保存されない。送信側のフレーム分割と、受信側の読み出し単位は一致しなくてよい。NETCONF の一チャンクを QUIC の一フレームと呼べない。証拠は、再構成済みバイト列と、その後に行ったアプリケーションの境界判定を分ける。

RFC 6241 の NETCONF では hello を end-of-message で区切る。双方が base:1.1 を示した後、第11版は RFC 6242 の chunked framing を使い、旧デリミタの注入を防ぐ。正しく区切れたことは、操作の妥当性、認可、効果を証明しない。

<ok/> の意味を広げない

NETCONF は message-id で RPC と rpc-reply を対応させる。rpc-error は失敗を表し、<ok/> はそのプロトコル要求に返すデータやエラーがなかったことを示す。並行処理を取り違えないための重要な証拠だ。

しかし、<ok/> はネットワーク観測ではない。edit-config や commit については、対象データストア、操作オプション、取引 ID、前後のハッシュ、後続エラーやロールバックを保存して初めて、サーバーが何を受け入れたかを説明できる。何が実際に適用されたかは次の層で確認する。

認可を操作単位で証明する

NACM は NETCONF ディスパッチャーから始まり、操作、データ、通知に別の判断を行う。読めるインターフェースを編集できるとは限らず、サブスクリプションを作れても通知の一部が見えないことがある。

主体、操作、対象パス、有効規則集合、該当規則、判断、ポリシー版を残す。「permit」だけではなぜ許されたかが分からず、TLS subject だけでは認可の有無すら分からない。通知が来ない場合も、イベントなし、フィルター除外、アクセス制御、配信障害を区別する。

running、intended、operational を同一視しない

RFC 8342 は conventional、intended、operational のデータストアを分ける。running から intended への変換があり、operational は適用済み設定とシステム状態を含む。参照先リソースが存在しない場合、意図はあっても operational に現れないことがある。

成功応答は、サーバーがデータストア操作を受け入れた証拠になり得るが、システム適用の証拠ではない。時刻と origin を持つ operational の読取り、逸脱やリソースエラーが次に必要になる。それでもデータプレーンとは別であり、ルーティング、隣接、転送、アクセス制御、サービスの能動試験へ進む必要がある。

通知ストリームに契約文脈を戻す

RFC 8639 のサブスクリプションは、ID、受信者、ストリームまたはデータストア、フィルター、ライフサイクルを持つ。RFC 8641 は周期型と on-change 型 YANG-Push、dampening、同期を追加する。

専用単方向ストリームはきれいな輸送路だが、契約を内包しない。更新を読むには、サブスクリプション ID、有効フィルター、データストア、トリガー、周期または抑制、受信者、認可版、ストリーム ID、終了事象を結ぶ。完全なバイト列でも、フィルター済み・遅延済みの部分ビューであり得る。

記録が指す現実を独立して観測する

最後の証拠は草案の外にある。経路ポリシーなら RIB/FIB、隣接、伝播、能動トラフィック試験。アクセスなら実行経路の検査。テレメトリなら独立した配信・損失窓である。装置と意図に応じて計器を選ぶ。

Heng Lu のランニングコード優先という考え方は、文書と記録が期待を記述し、実装と観測が出来事を示すという境界を守る。最小初期仕様は、相互運用の共通事実を決定的にしつつ、信頼、認可、再試行、結果の判断を各運用者に残す。現実の層と象徴権力は、整った記録が、その記録が説明する現実の代用品になる危険を示す。

第11版が与えるのは万能の証明ではなく、よく分けられた通路である。その分離を証拠設計にも維持することが、標準化案の価値を実運用へ移す条件になる。 公式の改訂アーカイブは、ここで用いた版の境界を保存している。