要約

  • 10月26日のRIPE 93で、BIRD開発責任者Maria MatejkaはNETCONF/XML、RESTCONF/JSON、CORECONF/CBORを比較した。
  • 本人のYANG変換案には、JSONの文字列"+3"がXMLを経て数値として読み直される例がある。

小さなプラス記号が検問所で足止めされた。入るときは文字列の一部だったのに、出るときは数字の同伴者になっていた。字面は変わらない。ネットワーク機器が受け取る設定値の意味が変わる。この検問官こそ、APIの間に置かれた変換プロキシだ。

10月26日のRIPE 93の講演で、CZ.NICのBIRD開発責任者Maria Matejkaは管理方式の数を数えた。本人の発表資料はNETCONFとXML、RESTCONFとJSON、CORECONFとCBORを順に扱う。YANGが共通のデータモデルを記述しても、各形式が運ぶ型の表現は違う。入口を増やすほど、間で荷物を開ける人の判断が重くなる。

Matejkaが3月に公開した個人提案には、その判断を試す例がある。YANGの一項目がint32とstringのどちらも許す。JSONの"item": "+3"は、RFC 7951に従えば文字列だ。XMLにすると+3という文字は残るが、引用符が伝えていた型の手掛かりは消える。次の装置がunionを解釈すると、整数側を選びうる。書類の中身は同じに見え、担当窓口だけが変わった。

提案は変換器にYANGモデルでの解釈、適切な出力形式の選択、検証、往復後の型確認を求める。別のunion要素として読み直されたら警告し、元の型を示す注記も提案している。IETFの記録では、この3月の個人草案は期限切れで保存されている。10月の発表は、その先にある運用上の問題を改めて照らした。

型の境界は+3だけにない。RFC 7951では小さな整数はJSONの数値になる一方、int64、uint64、decimal64は文字列になる。CBORにはさらに小型のタグ表現がある。表面の文字だけ見てモデルを読まない代理装置は、いつの間にか設定の意味を決める役員席に座ってしまう。

発表資料にはCORECONFの未完成の部分も明記される。いま動かしている経路については、値を各形式の端から端まで通し、機器に実際に反映された型と値を照合したい。記録するのはバイト列だけでは足りない。身分証も一緒に残す。

一次資料