要約

  • draft-ietf-netmod-yang-anydata-validation-00 は、符号化されたデータノードの識別情報から RFC 8525 の YANG Library を引き、anydata 配下に対応するスキーマを探す方法を示した。
  • anydata-complete は対応スキーマの全制約を適用する一方、anydata-candidate は制約検査を行わない。どちらも送信元、権限、運用状態、転送、事業成果を単独では証明しない。

監視画面の緑色は、ときに質問を終わらせてしまう。だが、数か月前のペイロードを同じバリデータで再生して結果が変わったとき、問題はデータなのか、モジュールの revision なのか、feature や deviation なのか。検証時の YANG Library が残っていなければ、緑色は再現できない記憶にすぎない。

revision 00 の Validating anydata in YANG Library context が扱ったのは、この接続点だった。YANG 1.1 の anydata は、YANG でモデル化できるものの、親モジュールの設計時点では具体的なモデルが分からないノード集合を格納する。フィルター、編集、instance data、通知、YANG-Push で便利だが、受信側は中身をどのスキーマで評価するか決めなければならない。

草案は符号化に残る識別子を使う。XML では local name とモジュールの XML namespace、JSON ではデータノード識別子またはモジュール修飾名、CBOR では SID、SID delta、namespace-qualified name、instance-identifier などである。その識別子から、YANG Library にある対応ノードを探す。

しかし YANG Library は単一の辞書ではない。RFC 8525 では datastore が schema を参照し、schema は module-set の和集合である。モジュールには revision、submodule、feature、deviation が伴う。content-id は Library の情報が変われば変化するが、実装固有であり同じ内容から常に同じ値が得られる保証はない。schema mount の下なら、さらにマウント先の文脈が必要になる。

candidate の合格は complete の途中結果ではない

草案が分けた二つのモードには明確な非対称性がある。anydata-complete は anydata subtree の内容を検証し、対応スキーマにあるすべての検証規則への適合を求める。anydata-candidate は constraint checks を適用しない。

名称は RFC 7950 section 8.3.3 の検証時点を参照する。running と startup では編集やコピーの終わりに制約を強制し、candidate datastore では commit または validate まで遅らせられる。だから candidate の合格を「完全な YANG 適合」と表示してはならない。構造を候補経路が受け入れたことと、全制約を通過したことは別の証拠である。

complete の合格にも条件が付く。それは指定した符号化、Library snapshot、datastore、schema、module-set、mount context、validator build の下で、実装が適用した規則に違反を見つけなかったということだ。別の環境へ移しても自動的に同じ結論になるわけではない。

失敗から分かるのも、型、範囲、must、when、要素数、未知ノード、文脈不一致などの限定された診断である。送信者の悪意は分からない。中継処理の書き換え、受信側の Library 選択、バリデータ差異も原因になり得る。失敗は隔離の根拠にはなっても、帰属の判決ではない。

草案は、負のインターフェース octet counter が YANG-Push で大量分析に入り、集計、請求、容量計画を誤らせる例を挙げる。完全検証はこの種の型・範囲違反を発見できる可能性がある。しかし値が非負であることは、最新性、欠落のなさ、送信元、対象インターフェースを保証しない。

再現できる検証票を設計する

検証票には payload hash、取得時刻、encoding、復号した node identity を置く。YANG Library の content-id と凍結 snapshot、datastore と schema、全 module-set、module/submodule revision、feature、deviation、mount path を結び、validator の名称、build、flags、選択モード、diagnostic、処置を残す。

これは監査向けの飾りではない。feature の変更でノードが消えることがある。deviation は制約を変える。mount point は同じ名前の探索文脈を変える。validator upgrade も parser behavior を動かす。同一 bytes の合否が反転したら、まず文脈差を調べられるようにするための運用データだ。

草案は non-conforming message の扱いを利用者に委ね、無視、記録、alert などを例示した。検証器の外に意思決定が残る点は重要である。どの失敗で自動処理を止め、どれを retry し、どれを人が確認するかは、結果の責任を持つ組織が決める。

文書はすでに失効している

Datatracker が示す最新 revision 日は 2025 年 12 月 2 日で、履歴には同日に WG revision 00 が公開された記録がある。本文の有効期限は 2026 年 6 月 3 日だった。現在の表示は Expired Internet-Draft、Expired & archived、Dead WG Document、IESG Expired で、構造化された Intended RFC status は None である。

原稿の masthead には Intended status: Standards Track とあるが、これは当時の原稿ラベルであり、IETF の承認ではない。セキュリティ分析は未完成で、IANA request はなく、Datatracker に shepherd もいない。

Implementation Status は libyang の anydata-candidate branch を挙げ、RFC 化の前に節を削除するよう求めていた。branch の存在は code path の試行を示せるが、merge、独立実装、相互運用、配備は証明しない。本稿はこの記述から運用実績を推定しない。

隣の証拠を代行させない

RFC 8342 は running、intended、operational を分ける。schema-valid な値でも device が適用した証明にはならない。RFC 8341 の access control は別の判断であり、構造適合は NACM authorization ではない。RFC 8639 と RFC 8641 が扱う subscription と delivery についても、valid subtree は event loss、replay、順序、上流改変を排除しない。

送信者 identity、transport integrity、custody はそれぞれの記録が要る。実機 counter、FIB、packet capture、遠隔観測、請求照合も別の層である。機械可読な合否だからといって、バリデータに全層の権限を集めてはいけない。

revision 00 が残した価値は、万能の valid badge ではない。opaque だった subtree を明示した文脈で試験し、強さの異なる二つの結論を区別する発想である。文脈と版を残せば障害範囲を狭められる。残さなければ、緑色は検証不能な約束になる。

出典

草案：revision 00、Datatracker の現状、履歴。

技術的境界：RFC 7950、RFC 8525、RFC 8342、RFC 8341、RFC 8528、RFC 8639、RFC 8641。

分析枠組み：Minimum Initial Specification、On Reality Layers、Running Code Primary。