要約

  • RFC 5381は、WSDLから生成したJavaクライアントとサーバー骨格だけでなく、資源の限られた装置上でHTTP、SOAP、NETCONFを分離して実装する経路も記録した。
  • SOAPヘッダーの処理を省けることと、セッションをcookieで相関した独自方式は、軽量化がそのまま標準準拠や処理結果を意味しないことを示す。

デスクトップの抽象と装置の現実

NMS側では、Apache AxisがWSDLを読み、Javaのstubを生成する。開発者はSOAPの構文を直接扱わず、get-configやedit-configに対応する型付きインターフェースを使える。これは開発負担を確かに下げる。

装置側の条件は異なる。RFC 5381は、メモリ容量のためJava環境や一般的なWeb Servicesツールを搭載できない場合を想定する。その場合、既存のHTTPデーモンにSOAPモジュールを接続し、NETCONFサービスプロバイダーへ本文を渡すC実装が選択肢になる。SOAPヘッダーは任意であるため、資源不足なら必須部分だけを解析する構成も示される。

ここで重要なのは、軽量化を否定することではない。何を省いたかを契約として残すことだ。拡張ヘッダーを処理しない装置が、受信した未知要素をどう扱うのか。TLS終端後の主体情報をどこへ渡すのか。SOAPモジュールがNETCONFエラーとHTTPエラーをどう対応させるのか。これらはメモリ節約の副作用ではなく、相互運用性の条件である。

同じWSDLでも、同じサービスとは限らない

RFC 5381は、WSDLとXML Schemaからクライアントstubとサーバーskeletonを生成する手順を詳しく説明する。生成物は双方のメッセージ形を揃える。だがskeletonはテンプレートであり、装置固有の処理は追加しなければならない。

さらに、基礎のWSDLにはservice要素がなく、別のWSDLがendpointを補う。装置機能のデータモデルも別途schemaとして接続する。したがって「同じWSDLから生成した」という一文は、実際には複数の入力、endpoint定義、データモデル、生成ツール、手書きコードを省略している。

NMSが完全なAxis実装を使い、装置が小さな独自パーサーを使うなら、両者が同じdescriptionを参照していても、受け入れる入力空間は同一とは限らない。正常系のデモは通っても、未知ヘッダー、順序、再接続、エラー処理で差が現れる。

相互運用試験は、生成されたメソッドが呼べるかだけでなく、両端が同じ失敗を同じ意味で扱うかを確認しなければならない。

cookieが接続の代わりになった瞬間

セッション維持では、さらに大きな契約変更が起きた。RFC 4743は、HTTP上のNETCONFセッションを持続するトランスポート接続の状態に結び付けた。RFC 5381の実装は、一般的なHTTP処理の無状態性に対応するため、NETCONF session-idをHTTP cookieにも書き込んだ。

装置はhelloへの応答で値を割り当て、NMSはXML要素とcookieの双方でそれを返す。ペアの内部では合理的である。しかしRFC 5381自身が、この代替bindingはRFC 4743準拠実装と相互運用しないと明記する。

資源制約や既存ミドルウェアへの適応が、公開されたセッション所有権を私的ルールへ変えたのである。接続が切れてもcookieが残る場合、負荷分散で別プロセスへ到達した場合、XMLとHTTPヘッダーが食い違う場合、どの状態が正しいのか。標準と実装が別の答えを持てば、両方が正常に動いているほど故障原因は見えにくい。

解析成功から装置反映まで

小さなSOAPパーサーが必須部分を正しく処理したとしても、それは最初の関門にすぎない。NETCONFサービスはメッセージを解析し、能力を確認し、セッションへ結び、主体の権限を評価し、対象datastoreへ操作を適用する。その後、設定が装置機能へ反映され、観測可能な挙動になる。

HTTP 200は入口の受領証である。SOAP Faultがないことは、信封層の受領証である。rpc-replyはNETCONF処理の結果を表せるが、内容を読まずに成功とみなせない。commitの記録も、ハードウェアや転送面が意図通りになったことの独立証明ではない。

制約装置ほど、この鎖を短いログ一行へ圧縮しがちだ。しかし記録容量が限られるなら、なおさら各段階の最小証拠を設計時に決める必要がある。後から完全な監査ログを要求しても、存在しなかったデータは復元できない。

HTTPSが守るもの、守らないもの

RFC 5381は、SOAP bindingでTLSを使い、認証と暗号化を確保するよう求める。これはNETCONF/SOAP/HTTPSの通信路を守る。

TLSはcookieが標準のセッション規則に従うことを証明しない。認証された主体が特定の設定を変更できるとも限らない。暗号化された要求が正しいdatastoreを対象にしたか、装置へ反映されたか、サービス目的を達成したかも別問題である。

IESG noteは、当時SOAPだけを実装し、少なくともSSHも提供しないNETCONF実装は標準に適合しないと指摘した。チャネルが安全でも、実装全体の必須面が揃うとは限らない。

歴史化された後に残る小さな実装

後年、RFC 6241とRFC 6242がNETCONFとSSH transportを更新し、RFC 9900はSOAPとBEEPの旧transportをHistoricとした。ポートの割当も解放された。

公的な生命周期は、装置内のCモジュールやコピーされたschemaを消さない。RFC 9900についての既存記事は、レジストリ上の解放と現場の撤去を分けて扱う。本稿が所有するのは別の問いだ。残存実装が見つかったとき、どのSOAP部分を実装し、どのセッション規則に従い、どの結果証拠を残すのかを誰が説明できるか。

Heng Luのrunning-code規律に従えば、WSDLの存在は装置動作の証明ではない。小さな実装は価値があるが、小さいから責任が小さいわけではない。

出典