要約

  • draft-ietf-netconf-yp-transport-capabilities-07 は、YANG通知で利用できる転送方式、符号化、安全プロトコルを、実装時資料または稼働中サーバーから発見できるようにする。
  • それは候補の一覧であり、特定の組合せが現在有効であること、受信先が許可・到達可能であること、establish-subscription が受理されたこと、配信が始まったことまでは証明しない。
  • 実装時情報と実行時情報は、出所も鮮度も役割も異なる。「対応済み」という一つの値に潰してはならない。
  • 観測、選択した組合せ、ポリシー、受信者、要求、結果、フォールバックを結ぶ能力から購読までの意思決定レシートが要る。これは編集上の提案であり、IETF草案の要件ではない。

一覧表の外で決まること

新しいネットワーク装置からテレメトリーを受け取りたいとする。管理システムはまず能力ツリーを読み、HTTPSの下にXMLとJSON、TLS 1.2とTLS 1.3があることを知る。別のUDP-notifの項目にはJSONとCBOR、DTLS 1.2とDTLS 1.3が並ぶ。装置が挙げていない方式を最初から除外できるため、発見機構としては有用だ。

ところが運用画面がそれを「通知対応」という印だけに変えると、決定の段階が消える。どの組合せを選んだのか。どのポリシー版が許したのか。情報は製品資料から来たのか、この装置を今読んだのか。管理主体はその受信先への購読を作る権限を持つのか。発行側は要求を受理したのか。最初の通知は届いたのか。

第07版は2026年8月17日に公開された。Datatrackerの最終更新日は9月8日で、8月25日に告知されたIETF Last Callの意見期限も同日だった。調査基準日の9月9日現在、文書はProposed Standardを目指す現役のInternet-Draftで、IESGへ提出済み、状態は「Waiting for AD Go-Ahead」である。期限を過ぎたことはRFC化や最終承認を意味しない。

草案は可能性を見つけやすくした。可能性を命令へ変える責任は、その先に残る。

「対応」には二つの時刻がある

基盤となるRFC 9196は、能力情報を二つの経路で提供する。実装者は装置が動く前から、YANG instance dataのファイルとして情報を配布できる。稼働中のサーバーはNETCONFまたはRESTCONFを通じて現状を返せる。

前者はNMSの設計者、インテグレーター、購入を検討する運用者に役立つ。製品型式や実装が備える設計上の範囲を早い段階で示すためだ。後者はモデル駆動型のアプリケーションに必要で、ライセンスやハードウェア制約、運用中の変更を反映しうる。RFC 9196は、以前に得た情報どおりの機能を発行側が実装しているか確認する用途も明示している。

従って、製品ファイルと実機の回答が異なっても、直ちにどちらかが虚偽とは限らない。製品全体では可能でも、その個体のライセンスでは無効かもしれない。実行時の回答も、観測した瞬間には正しく、その後に古くなりうる。能力が運用中に変わる実装について、RFCはsystem-capabilitiesコンテナーのon-change通知を推奨する。ただし利用者が変更を受け取り、過去の選択へ結び付けなければ意味は残らない。

記録には、実装時ファイルか実機照会か、取得元、取得方法、モジュール版、装置とソフトウェア、観測時刻、鮮度の期限が要る。「対応」は嘘でなくても、座標を失えば自動判断には粗すぎる。

候補集合と実行結果を混ぜない

新しいtransport-capabilitiesコンテナーには、転送プロトコルをキーとするtransport-capabilityリストがある。その中にsecurity-protocolとencoding-formatの各leaf-listが置かれる。この構造は候補探索に向くが、選択済みの組合せを記す台帳ではない。

二つのリストが分かれているからといって、草案があらゆる直積の動作を誤って保証している、と断定するのも不正確だ。証拠から言える範囲は狭い。利用したい転送・符号化・安全方式がそれぞれ掲載されていても、その三点の組合せが今の個体で成功する証明にはならない。組合せを明示して試し、その結果を残す必要がある。

RFC 8639は、能力発見の次にある状態遷移を定義する。動的サブスクリプションは、購読者が要求を送っただけでは発行側に存在しない。発行側がestablish-subscriptionを受理して初めて作られる。拒否理由は複数あり、次の試行で成功しやすいパラメーターを構造化して返す場合もある。

受理も配信完了と同じではない。発行側に状態が生まれた証拠であって、通知受信先の到達性、最初の通知、その後の継続までは示さない。運用表示は「発見」「選択」「ポリシー許可」「受理」「配信中」を分けるべきだ。

管理経路があっても、通知先は別である

草案は、オーケストレーターと装置の間に管理ネットワークがあり、管理接続と装置側エンドポイントが構成済みだと仮定する。だから能力を読める。

しかし、その前提が通知の宛先まで準備するわけではない。NETCONFまたはRESTCONFで認証された主体が、任意の受信者に流れを作ってよいとも限らない。認証は管理口にいる主体を特定する。NACMや組織の規則が操作を制限し、安全部門が方式を選び、テレメトリー部門が受信基盤を運営し、別のチームが経路を持つこともある。

分業では、緑色の能力表示を全員が別の意味で読む。ネットワーク担当は安全審査済みと思い、安全担当はオーケストレーターが推奨方式だけを選ぶと思い、受信担当は装置が到達性まで検査すると思う。判断の受け渡しが見えなければ、局所的には合理的な期待が一つの無責任な動作になる。

草案は新しいノードをread-onlyかつセキュリティ上の機密ではないとし、安全で相互認証されたNETCONFまたはRESTCONFとNACMによるアクセス制御を前提にする。能力一覧を秘密情報だと誇張する必要はない。問題は、公開可能な事実であっても、許可されていない命令へ変換できることだ。TLS 1.2が読めたことと、その受信先に採用してよいことは同義ではない。

標準化の進捗と運用実績は別の証拠

Datatrackerは9月8日のYANG検証についてエラー0、警告0を示す。現行のセキュリティレビューはReady、トランスポートレビューはAlmost ready、IANAは作業が必要、専門家レビューは完了と記録されている。いずれも有用な工程情報だが、本番配信の測定値ではない。

第07版の実装状況には、HuaweiがVRPのYANG-Push publisherで、CiscoがIOS XRで実装したと書かれる。同じ節にはRFC Editorが公開前に削除するよう注記がある。動くコードがあるという申告であり、第07版の公開相互接続試験、普及率、製品認証、全組合せの成功証明ではない。

dtls12 identityの説明も境界を教える。DTLS 1.2をobsoleteとし、有効化を推奨しない。一方、HTTPSの例にはTLS 1.2が掲載される。ここから「1.2はすべて禁止」と短絡してはならない。ポリシーは文字列ではなく、プロトコルidentityと該当する規範を読まなければならない。

能力から購読までを一枚にする

提案する能力から購読までの意思決定レシートは、YANGモデルを変えるものではない。観測を行動へ変える時点で運用側が作る記録である。

まず装置、製品系列、モジュール版、ソフトウェアbuildを記す。実装時ファイルか実機のNETCONF/RESTCONF応答か、出所、観測時刻、失効規則を示す。見えた転送項目と、実際に選んだ転送・符号化・安全方式の三点も残す。

次に操作主体、受信者のidentityとendpoint、ローカルポリシー版、購読パラメーター、試行時刻を結ぶ。結果は単純な成功・失敗では足りない。受理、拒否、timeout、後日の終了、受理されたが初回配信なし、を区別する。エラーhint、再試行、fallback、弱い選択を許可した責任者も添える。

このレシートはプロトコルの意味を増やさない。「製品資料にあった」「実機が返した」「ポリシーが許した」「発行側が受けた」「受信側が得た」という別々の真実を、一つの根拠のない結論へ圧縮させないだけだ。

The Policy Mirrorの問いに沿えば、可能性は能力ツリー、許可はポリシー、存在はサブスクリプション状態機械、効用は受信側に書かれる。Running-Code Primacyは、その実行記録を接続する。Reality, Not Advocacyは結論の範囲を守る。草案が約束するのは良い候補一覧であり、自動的な配信ではない。選んだ注文には、運用者自身の記録が必要だ。

出典