要約

  • Matejkaは、複数の管理プロトコルがあってもルーター内のモデルを一つにまとめる規則は別に必要だと示した。
  • IPv6アドレスを16バイトと文字列のどちらで保持するかが、YANGデータと各ソフトウェアの正本を決める問題を浮かび上がらせる。

BIRD利用者は、コマンドラインを読み取ってJSONへ変換する道具に頼る状況から、標準APIを求めた。Maria MatejkaのRIPE 93発表は、接続方式を選べば終わる話ではなかった。NETCONF、RESTCONF、CORECONFを並べたあと、彼女はLinuxルーターの内部にある複数のモデルをどう扱うかへ議論を移した。

NETCONFはSSH上のセッションで設定を操作する。RESTCONFはHTTPを使い、接続を長く保たないブラウザー型のクライアントにも合う。CORECONFはCoAPとCBORを使う小型機器向けの道を示す。YANGはデータ構造を定義し、各方式はそのデータを運ぶ方法と表現を選ぶ。

Matejkaの例では、BIRD、NetworkManager、systemdが一台のLinuxルーターに並ぶ。それぞれ別の仕事を持ち、別々のデータツリーを管理する。運用者が設定する対象は一台でも、ソフトウェア側には複数の管理境界がある。発表で示された設計は、そのツリーを顧客向けの一つの端点へまとめる方法を定めていなかった。

IPv6アドレスの例は、境界を単なる通信形式の話にしない。内部では16バイト、外から見ると文字列という表現があり得る。YANGのデータストアと各ソフトウェアの内部構造のどちらを正本にするのか。値が食い違ったときに誰が決めるのか。Matejkaは、スキーマを知らなければプロキシを作れず、XMLやJSONの変換だけでも足りないと説明した。YANGに基づくパーサーとエンコーダーは将来のプロキシを支える候補であり、統合済みの仕組みとして紹介されたわけではない。

CORECONFの文書は2026年10月31日時点で、IETF Datatrackerに期限切れのInternet-Draft 21として掲載されている。最終改訂は3月2日で、IESGへの提出マイルストーンは翌11月だ。草案の状態は接続方式を選ぶ材料になる。一方、複数のソフトウェアが持つモデルの所有者と正本は、実装側が決める必要がある。

次の判断を変える証拠は、BIRD、NetworkManager、systemdを同じ端点から読み、限定した設定変更を実行し、各値の出所と正本を表示する相互運用試験だ。RIPE 93の発表と公開草案には、その試験結果は載っていない。値の由来まで追える複数実装のデモが出れば、統合の設計を運用上の契約として評価できる。

一次資料：RIPE 93の発表 · 公式文字起こし · BIRDチーム · RFC 6241 · RFC 6242 · RFC 8040 · RFC 7950 · RFC 7951 · RFC 9254 · CORECONF草案の状態。