要約

  • draft-ietf-netmod-yang-xml-00 は、YANG ノードを XML の要素、名前空間、順序、値、参照として表す規則を、言語仕様から切り出してまとめる。
  • well-formed、schema validation、Canonical XML の一致は表現層の証拠である。実効デフォルト、ユーザー順序、RPC の受理、datastore の変化、operational state、外部効果までは証明しない。

変更前の二つの設定スナップショットを考える。一方はデフォルト名前空間を使い、もう一方は任意の prefix を使う。空白と属性順も違うが、Canonical XML に通すと同じ digest になった。ところが片方のサーバーは schema default を trim し、もう片方では同じ値が明示的に書かれていた。次のモデル更新で default が変われば、二つの履歴は同じ意味を持たない。

2026年6月8日付の XML Encoding of Data Modeled with YANG は、RFC 7950 にあった XML 符号化の規範定義を独立させる Standards Track 案である。設定、状態、RPC/action の引数、通知を対象にする。ただしこれは12月10日に期限を迎える Internet-Draft で、IANA と Security Considerations はなお FIXME である。完成済み標準や製品適合性として扱う根拠はない。

prefix の綴りより namespace の結び付き

YANG データノードのインスタンスは XML 要素になり、local name はノード識別子、namespace は定義元モジュールから来る。トップレベルで namespace を設定し、augment された子が別モジュールに属すればそこで切り替える。

同じ URI に結び付く prefix は違ってよい。文字列比較だけなら偽の差分が生まれる。しかし prefix を機械的に統一し、元の binding を落とせば、別の名前を同じものにする危険がある。

identityref の値も namespace-qualified name であり、同じ identity に異なるローカル prefix を使える。instance-identifier はすべてのノード名に明示的 prefix を要求するが、その prefix もインスタンス内だけのものだ。正しく解決するには対象 schema が必要で、解決できても該当 datastore にそのノードが存在する証明にはならない。

順序を消してよい場所と、消してはいけない場所

通常の container の子は任意順でよい一方、RPC/action の input/output は schema 順になる。list の key は先に置かれる。list と leaf-list が ordered-by user ならユーザー順を保持し、system ordered なら実装が順序を決める。

全要素をソートする diff は、無意味な違いを減らすと同時に、優先順位や first-match policy を破壊し得る。逆にすべての移動を変更とすればノイズになる。必要なのは YANG path、ordered-by、元の配列、サーバー readback を一つの記録に結び付けることだ。

XML に見えない default が動作を決める

第00版は NETCONF の default-handling mode を定義しない。RFC 7950 は default がいつ in use になるかを定め、条件が成立する場合はノードが存在するかのように動作することを要求する。when や if-feature が false なら適用されない。RFC 6243 は report-all、trim、explicit、report-all-tagged を定義する。

したがって XML 応答に leaf がないからといって、実効 tree に値がないとは言えない。default と同じ値が書かれていても、client が明示設定したのか、server が補ったのか、保存されているのかは分からない。比較する view を、wire bytes、stored configuration、defaults-in-use を含む accessible tree、特定の with-defaults 応答のいずれかとして宣言しなければならない。

XML C14N はアプリケーション規則を取り込まない

Canonical XML 1.1 は文字 encoding、属性順、namespace declaration など物理表現の自由度を安定化する。W3C 自身が、アプリケーション固有の同値規則は汎用 XML アルゴリズムでは尽くせないと説明している。canonical form が違ってもアプリケーション上は同値になり得るし、一致しても YANG の外部規則までは証明しない。

YANG では module revision、features、deviations、型の lexical/canonical form、defaults、order、constraints、reference resolution が意味を作る。C14N は schema を選ばず、default を展開せず、leafref を参照解決しない。

RFC 8525 の YANG Library はサーバーが宣言する schema-set を示すが、実プロセスがロードしたものとの照合が要る。RFC 8528 の schema mount では、同じ mount point の別インスタンスに異なる mounted schema を置ける。切り出した同じ XML fragment でも、mount instance が変われば解釈が変わる。

RFC 7952 の metadata は XML attribute として運ばれる。未知属性を削る中継は通常ノードを残して provenance や origin の条件を失わせ得る。モデル不明の anydata や anyxml については、他 encoding との可逆変換も一般には約束できない。

protocol receipt の先に state がある

有効な XML ファイルは NETCONF RPC の受信証拠ではない。RFC 6241 の <ok> は処理に error/warning がなく返す data がないことを示すが、後の物理効果を認定しない。

変更記録には request bytes、message-id、認証 session、capabilities、YANG Library、reply、datastore の before/after を結ぶ必要がある。RFC 8342 が running、intended、operational を分けるのは、有効設定、変換後の意図、実際に使用される状態が離れ得るからだ。最後に reachability、policy hit、service behavior など外部観測を置く。

標準は期待できる意味を定義し、running code は実際の帰結を示す。両者をつなぐことが厳密さであり、一つの緑色バッジにすべてを代弁させることではない。

主要資料