要約

  • 明示的な非テンプレート設定が最優先で、近い祖先が遠い祖先に勝ち、同じノードではクライアントのリストで先に置かれた適用可能なテンプレートが競合に勝つ。
  • 再現には完全かつ同時点の running と system、定義、適用位置と順序、I-Regexpによるキー照合、明示的上書きが必要だ。それでも入力主体、競合の不在、NACM、実装同一性、運用収束、通信結果は証明しない。

設定ファイルを整形する処理が、テンプレート名をアルファベット順に並べ替えたとする。普通のタグ一覧なら無害に見える。しかし draft-tt-netmod-yang-config-templates-03 では、その整形が設定変更になり得る。順序が、同じ値を提示する二つのテンプレートのどちらを採用するか決めるからだ。

優先順位は三段で読む必要がある。まず、running または system に明示された通常設定がテンプレート由来の値より強い。次に、対象ノードに近い内側の祖先で適用されたテンプレートが、外側の祖先のものより強い。最後に、同一位置での競合はクライアントが渡した順序で解決する。

草案の例は方向まで示す。ethernet-interface base-interface の順で適用すると、一致するEthernet項目には先頭テンプレートのMTU 1500が入り、後ろの65536にはならない。つまり先に並ぶ適用可能なテンプレートが高優先だ。名前を集合として保管した時点で、再現に必要な情報は失われる。

メタデータ更新にも差がある。空でない値はリスト全体を置き換え、空文字または空白だけなら適用を削除し、メタデータ自体を送らなければ既存リストを残す。監査記録には「追加・削除」だけでなく、受信した完全な置換値が要る。

照合対象もスナップショットの一部

テンプレートは、組み込み型が string、またはその派生型であるリストキーに正規表現を使える。基準はRFC 9485のI-Regexpで、XML Schema正規表現の互換性を意識した限定サブセットである。制限された文法であっても、パターン文字列だけから実際の一致集合は復元できない。

eth.* が何を選んだかは、その瞬間に存在したキーに依存する。インターフェース名が変わった、system 由来の項目が欠けた、別の更新後に採取した、といった差で結果は変わる。パターン、候補キー、規則版、実装解釈を同じ証拠包に含めるべきだ。

テンプレートは部分断片でもよい。サーバーは可能な範囲で定義を検証し、適用後の統合結果はYANG制約を満たさなければならない。一方、Datatrackerが抽出モジュール ietf-config-template (revision 2026-07-03) に示す0エラー・0警告は文書ツールの記録である。NETMOD採択、IETF承認、製品実装、相互運用性の試験結果ではない。

intended は原因一覧ではない

NMDAでは、running は定義、適用メタデータ、明示値を含む簡潔な表現のまま残る。展開後の結果を示すのが intended である。適用中テンプレートが running または system で変われば、意図した設定にも反映される。

参照中のテンプレートを削除しようとすると、草案は data-missing で拒否するよう求める。先に全適用箇所を更新し、その後で定義を削除する。ただし、これは手順の順序であって、複数要求をまたぐ原子性の保証ではない。確認と削除の間に別クライアントが参照を追加できる。トランザクション、ロック、保守手順は実装ごとに証明が必要だ。

一回の intended 読み出しも、元の要求を一意に逆算できない。異なる定義が明示値で隠されて同じ木を作る場合がある。競合する値がなければ、順序が違っても出力は同じだ。読み出しは結果の観測証拠であり、履歴の完全記録ではない。

オフボックス再現の条件

独立展開器を使うなら、実験単位を固定する。草案と規則の正確な版、サーバーと展開器の実装識別子、同一時点の完全な running と system、全定義、適用パスと祖先深度、順序付きリスト、I-Regexpと候補キー、明示上書き、そして各部分が同じ観測に属することを示すバージョンや時刻関係である。

展開木だけでなく、この入力包全体をハッシュ化する。サーバーの intended とノード・値単位で比較し、一致すれば「この入力では二つの変換が一致した」と言える。それ以上に、全ベンダーが同じ実装を持つとは言えない。

NETCONFやRESTCONFの成功応答は別種の受領証だ。後の伝播や適用を保証しない。RFC 8341のNACMは読み書きの可否を独立に決めるため、役割ごとの検査が必要になる。RFC 8342では intended と operational も別で、資源不足などにより意図が実行状態に現れないことがある。その先のFIB、パケット、サービスも個別に測るしかない。

文書上の二つの欄を混ぜない

第03版は2026年7月3日付である。本文ヘッダーは「Intended status: Standards Track」と記す。他方、Datatrackerはactiveなindividual Internet-Draft、streamなし、intended RFC statusなし、I-D Exists と表示する。二つの欄をそのまま伝えるのが正確で、ワーキンググループ採択やRFC化を推測してはならない。

情報源

一次資料：第03版、Datatracker、YANG 1.1 / RFC 7950、YANG Metadata / RFC 7952、NMDA / RFC 8342、NACM / RFC 8341、NETCONF / RFC 6241、RESTCONF / RFC 8040、I-Regexp / RFC 9485。改訂履歴：Datatracker history。 境界整理の参考：System Configuration 第20版、Lu Hengの実行コード優先、最小初期仕様、現実の層。