要約

  • draft-fedyk-netmod-yang-normal-form-00 は、文字列の元の字句表現を保存しつつ、等価比較、list key、設定用 leaf-list の一意性に決定的な正規化形式を使う案である。
  • MAC の例では、コロンとハイフン、大文字と小文字の違いが同じ12桁の比較値に収束する。pattern は入力構文を検査するだけで、許可された二つの文字列を同一にはしない。
  • Datatracker 上では active individual Internet-Draft、Intended RFC status は (None)、IESG state は I-D Exists である。一方、本文ヘッダーには Intended status: Standards Track とある。NETMOD 採択や IETF 承認を意味しない。

表示と比較を分業させる

48ビットの同じアドレスを、管理システムが異なる文字列で表すことがある。RFC 6991 と現行改訂版 RFC 9911 の IETF 共通 YANG 型はコロンで区切り、小文字を canonical と記述する。IETF 会合資料に示された IEEE 型はハイフンを使い、大文字を canonical とする。人には同じアドレスでも、string key では別値になり得る。

revision 00 は、この二つの役割を切り離す。受信した字句値は encoding と retrieval のために保持する。任意の normalized-form 拡張が決定的アルゴリズムを指定し、等価比較、list key の一意性、設定用 leaf-list の一意性だけがその結果を使う。

mac-48 の手順は限定的だ。まず各型の lexical pattern で検証し、区切り文字を除き、十六進数字を大文字にし、残った12桁を比較形式とする。したがって aa:bb:cc:dd:ee:ff、AA:BB:CC:DD:EE:FF、aa-bb-cc-dd-ee-ff、AA-BB-CC-DD-EE-FF はすべて AABBCCDDEEFF になる。草案は 0xAABBCCDDEEFF と表示するが、12桁の本体は 0x を除く部分である。

正規表現を広げるだけでは足りない理由もここにある。RFC 7950 の pattern は、string に許される入力を絞る制約である。組み込み string の canonical form は lexical representation と同じで、Unicode normalization も行わない。大文字と小文字を両方許しても case folding の命令にはならず、二種類の区切りを許しても等価性は生まれない。

同じデータが別の重複判定を受ける

拡張への対応は opt-in である。対応実装は正規化形式を使わなければならないが、非対応実装は通常の字句型を処理し続ける。YANG 1.1 も、未対応拡張を unknown statement として全体的に無視できる一方、対応を表明した拡張はその仕様どおり処理するよう定める。

既に aa:bb:cc:dd:ee:ff があり、別の場所から AA-BB-CC-DD-EE-FF が来た場合を考える。それぞれの schema node で表記が許可されていれば、対応実装は同一 normalized key として二件目を拒否できる。非対応実装は二つの string と見る可能性がある。= と !=、keyed list、設定用 leaf-list のすべてで差が表面化する。

従って duplicate receipt には文字列二つだけでは足りない。module revision、schema node、base type、normalized identity、実装と release、拡張対応の根拠、実際の normalized value を残すべきである。それがなければ「重複」は、どの規則が下した結論か分からない。

ステータスは三行を同時に読む

Datatracker は、この文書を active individual Internet-Draft とし、RFC stream と intended RFC status を空欄、IESG state を I-D Exists と表示する。また、誰でも I-D を提出でき、この文書には IETF endorsement も標準化過程上の formal standing もないと明記する。固定された本文は Intended status: Standards Track、有効期限を 2027年1月2日と記す。

本文ヘッダーは著者が掲げた目標であり、Datatracker は現実の手続状態である。埋め込まれた module の organization 欄に IETF NETMOD Working Group と書かれていても、現在の記録には WG adoption の証拠がない。

著者は LabN Consulting の Don Fedyk と Ericsson の Scott Mansfield である。Fedyk の公式プロフィールには24本の RFC、Mansfield のプロフィールには5本の RFC と複数の IETF–ITU-T liaison role が記録される。経験は提案を精査する理由にはなるが、組織的承認の代わりではない。

前史も確認できる。Mansfield の IETF 124 NETMOD 資料は IETF と IEEE の MAC 表記を比較し、一形式への移行、pattern の拡張、比較機構の追加、storage の変更、現状維持を選択肢として並べた。revision 00 は、既存の表示を残しながら比較機構を足す道を選んだ。

「等しい」が証明する範囲

同じ normalized form は、二つの許可済み入力が同じ宣言済み変換を通ったことを示す。XPath の equality は、その実装がその schema context で行った比較を示す。duplicate rejection は、ローカルな設定制約が発火したことを示す。

しかし、同じ物理 device、interface、owner を示すものではない。将来の別 identity に対する collision freedom、二実装の同一性、両端の extension support、同じ schema や XPath visible tree、既存 datastore の migration も証明しない。operator intent、authorization、forwarding table の統合、packet path、service outcome はさらに別の証拠である。

これは XDR のような通常の canonicalization とも違う。XDR は一つの external byte representation を出す。本案は複数の lexical representation を残し、限定された比較だけに別 identity を導入する。module file や schema diff が正しくても、このアルゴリズムが実行された証明にはならない。

問うべきことは明確だ。二つの string が YANG の判断に入った時、実装が typography ではなく宣言された value を比較したと、どの receipt が示すのか。