要約

  • 改訂11は、モジュール定義時のタグ、実装が付けるタグ、利用者が設定するタグを扱い、masked-tag と完全一致する値を除いた集合を operational state に示す案だった。
  • 残ったタグが立証するのは、特定のデータストア、スキーマ、権限の下でサーバーがその分類を返したことまでである。ノードの存在、値の鮮度、実装の挙動、草案の採用や配備は別の証拠を要する。

監視システムが「重要」と分類されたノードを検索し、三つのパスを受け取ったとする。想定していた四つ目は返らない。未分類だったのか、利用者がマスクしたのか、NACMで隠れたのか、現在のモジュール構成ではセレクターが解決できないのか。応答だけからは選べない。

この多義性こそ、YANG Data Model for Node Tags を読む入口になる。改訂11は ietf-node-tags モジュールを提案し、整数の id、nacm:node-instance-identifier 型の node-selector、tag と masked-tag の集合からなる関連リストを置いた。セレクターはスキーマノードにもデータノードのインスタンスにも向けられる。探索には operational datastore への <get-data> を示し、スキーマノードについては <get-schema> も挙げる。付録では、タグから得たパスを establish-subscription に渡す。

これは手順の例であり、稼働実績ではない。今回の資料群には、製品への搭載、独立実装、相互接続試験、実運用の証拠はない。

出所の説明と合成手順は完全には重ならない

本文は出所を三つに分ける。モジュール作者が設計時に付けるタグ、実装が能力に応じて追加するタグ、利用者が設定するタグである。利用者は出所を問わずタグをマスクできる。

ところが operational view の作り方を列挙する箇所では、モジュール定義時に割り当てられた system-origin のタグを加え、利用者が設定した intended-origin のタグを加え、masked-tag と等しい値を取り除く、と書かれている。実装追加タグだけの独立した手順は列挙されていない。

自動的な実装追加分をサーバー側の system 材料として読むのは妥当だろう。しかし、それは二つの記述をつなぐ解釈であって、明記された第四段階ではない。監査用のモデルは、原文よりも整然とした来歴を捏造してはならない。

マスクは、過去にタグが存在しなかったことを示す操作でも、タグが誤りだったという判定でもない。最終集合から同一文字列を引くだけだ。逆に、残った vendor:critical は正しさの証明にならない。誰が、いつ、どのソフトウェア版で、どんな観測を根拠に追加したかは、集合だけでは分からない。

草案は ietf:、vendor:、user: を予約する一方、未登録の接頭辞を持つタグも有効であり、実装は処理すべきだとする。登録が管理するのは名前空間である。コロン以後の主張を認証する制度ではない。整った名前で誤ったノードを説明することも、その逆もあり得る。

セレクターの背後にあるスキーマ

node-selector が型を持つことで、パスは自己完結して見える。実際には RFC 7950 のYANG規則に加え、RFC 8525のYANG Libraryが示すモジュール、改訂、feature、deviationが必要になる。同じ文字列でも、実効スキーマやマウント文脈が変われば解決不能になったり、別の対象を指したりする。

RFC 8342は intended と operational を区別する。草案も、利用者設定を intended-origin、合成後の表示を operational として扱う。だが operational は、サーバーが構成したデータストアの表示である。ハードウェアや転送の現実を直接観測したという意味ではない。

RFC 8341のNACMは、関連リストにも対象ノードにも閲覧制限を適用できる。RFC 6241のNETCONFとRFC 8040のRESTCONFで要求が成功しても、分かるのは、その主体にその取引で何が返ったかまでだ。欠落を即座に不存在と判定できない。

RFC 7952のmetadata annotationは、データインスタンスに伴う注釈である。node-tagsはセレクターとの関連を中央に集める。この差は来歴設計に重要だが、どちらも作者、時刻、保管経路、鮮度を自動的には与えない。

証拠を一段ずつ積む

文書の存在は、改訂11が提案されたことを示す。Datatrackerは、その文書がいつ更新され、いつ期限切れになったかを示す。接頭辞登録は名前空間の割当てを示す。タグ応答は、特定の権限とデータストアの下で、サーバーが合成後の値を見せたことを示す。

凍結したYANG Libraryに照らしてセレクターを解決できれば、そのスキーマに対象ノードがあると確認できる。さらに認可された読み出しが成功すれば、その取引でサーバーが返した値が分かる。しかし、鮮度、完全性、実装の正しさ、通知の欠落、FIBの状態、パケット転送、サービス結果は依然として未証明である。

RFC 8639とRFC 8641は購読とYANG-Pushを構成できる。RFC 9195とRFC 9196はインスタンスデータと能力の表現を助ける。それでも、分類トークンが全通知の到着や忠実な実装を保証するわけではない。RFC 9371のベンダー識別も名前の整理であり、製品挙動の承認ではない。

自動処理と結ぶと境界は一層重要になる。草案は、タグがノードの用途や攻撃経路を漏らし得ること、追加と削除を権限で守る必要があること、タグに基づく動作が対象外であることを明記する。タグだけで変更、遮断、許可を実行するなら、その判断権限は運用者側が別途定義しなければならない。

公開RFCの地位は継承できない

改訂11の日付は2023年10月21日で、本文上の失効日は2024年4月23日である。Datatrackerは現在、Expired Internet-Draft、Expired & archived、Dead WG Document、IESG Expired と記録する。想定されていた文書種別は Proposed Standard だったが、RFCにはならなかった。

YANG検証欄のゼロエラー、ゼロ警告は、提出モジュールが指定ツールの検査を通った証拠である。採用、相互運用、配備、正しい合成の証拠ではない。

近接するRFC 8819は、YANGモジュールに対するタグを標準化している。モジュール定義、実装、利用者、マスクという構成は重要な前例だが、対象はモジュールである。node-tags案はその発想をノードへ広げようとした。RFC 8819の標準としての地位を、期限切れ草案が借りることはできない。

Heng Luの最小仕様、権威、実装力、現実の層、running codeに関する論考は、ここでは分析の補助線に限る。文書、登録、ラベルは協調を助けても、採用と観測可能な運用は別層にある。これはIETF要件ではない。タグを探索の手がかりにとどめ、文書や登録制度の権威をノード事実へ転写しないための編集上の規律である。

出典

一次記録：改訂11、Datatrackerの現行状態、履歴。

モデルとアクセス：RFC 6241、RFC 7950、RFC 7952、RFC 8040、RFC 8341、RFC 8342、RFC 8407、RFC 8525、RFC 8526。

タグ、購読、周辺モデル：RFC 8639、RFC 8641、RFC 8819、RFC 9195、RFC 9196、RFC 9371。

分析の補助線：Minimum Initial Specification、On Authority、Implementation Power、Reality Layers、Running Code Primary。