要約

  • 不正な Trace Context だけを理由に管理 RPC を拒否することは推奨されず、RESTCONF の例ではリソース作成が成功した後に新しい未サンプリングのトレースが始まる。
  • 新しい traceparent はリセット地点以降を観測できるが、失われた親子関係や捨てられた tracestate を復元しない。
  • 認証済み要求、トレース処理、プロトコル応答、データストア、読み戻し、サービス結果を別々の証拠として結ぶ必要がある。

制御の成功と観測の失敗が同時に起きる

運用者が見る画面では、一つの変更が一本の木に見える。オーケストレーターからコントローラー、装置へ span が連なれば安心し、途中で途切れれば失敗を疑う。しかし、線が切れた場所と処理が止まった場所は一致するとは限らない。

RESTCONF 向け草案の第 11 版には、解析できない高位バージョンの traceparent と不正な tracestate を受けた例がある。サーバーはリソースを作成し、201 Created を返す。同時に version 00 の新しい traceparent を発行し、trace flags を 0 にして、tracestate を取り除く。

ここでは設定処理が優先され、観測の系譜だけが切り替わる。NETCONF 向け第 09 版も RESTCONF 草案も、Trace Context の値だけで RPC を拒否することを推奨しない。一方、拒否する実装には operation-failed のプロトコルエラーを要求する。

つまり相互運用上の重要点は「必ず継続する」ことではない。継続したのか、追跡をリセットしたのか、明示的に拒否したのかを、後から区別できることである。

トレース識別子の権限を狭く保つ

traceparent はトレースと親 span の関係を運ぶ。tracestate はベンダー固有の不透明な文脈を運ぶ。NETCONF では XML 属性、RESTCONF では HTTP ヘッダーになる。NETCONF 草案は、これらが設定データ、サービス識別子、状態そのものではないと明記する。

相互認証は通信相手を、NACM は操作権限を扱う。NETCONF の message-id はセッション内の RPC と応答を対応させる。RESTCONF のステータス、Location、ETag はサーバーの処理結果を示す。データストアの記録、設定の読み戻し、サービスの外部観測は、さらに別の層である。

トレースはこれらを探す索引になれる。しかし、索引が整っていることは内容の正しさを証明しない。逆に索引が壊れていても、記録された状態まで消えるわけではない。

W3C の処理モデルでは、有効な親がなければ新しい trace ID と parent ID を生成し、単独の tracestate は捨てる。信頼できない文脈を継承しないために必要な処理だが、旧トレースと新トレースの間には証拠上の継ぎ目が残る。

可観測性の穴を再実行で埋めない

最も危険なのは、span の欠落を実行の欠落とみなす自動再試行である。最初の書き込みが成功していれば、二度目の非冪等操作は別の実害を作る。しかも二度目だけがきれいなトレースを持つため、監査側は誤った実行を「唯一の成功」と見なしやすい。

追跡情報を無条件に信頼することも解決にならない。W3C は、サンプリングによるコスト増、偽の衝突、情報露出を挙げる。NETCONF 草案も、相関情報が管理ネットワークの把握に使われ得ると述べる。信頼境界でトレースを再開することは、プライバシーや防御上の正当な判断になり得る。

必要なのは、切断を禁止することではなく、切断を別の台帳で説明できるようにすることだ。

継ぎ目のための受領記録

入口で、ローカルな要求 ID、認証主体、適用した認可ポリシー、要求の指紋を保存する。次に Trace Context の処理結果を「なし・受理・リセット・拒否」のいずれかとして記録する。新しい traceparent が作られた場合はローカル要求と結ぶが、呼び出し側の不透明な tracestate に業務上の権威を与えない。

その後に NETCONF/RESTCONF 応答、ローカル取引またはデータストアの記録、時点を指定した読み戻し、独立経路からのサービス観測を並べる。一本の万能 ID ではなく、範囲の異なる受領記録を接続する。

これにより「元のトレースに装置 span がない」は再試行命令ではなく、接続記録の確認要求になる。「トレースが完全」も、読み戻しと結果観測がなければ完了証明にならない。

標準化されるもの、されないもの

両文書は 2026 年 9 月 17 日更新の有効な Internet-Draft で、Proposed Standard を意図している。最終 RFC、製品実装、展開実績ではない。YANG Library に能力が見えても、すべての span が収集されたことまでは示さない。

草案が提供するのは重要な境界線である。管理操作は追跡の失敗から独立して成功し得る。その後の説明責任は、実装と運用設計に残る。

情報源