要約

  • draft-ietf-netconf-error-registries-00 はYANGプロトコルのエラータグとエラーidentityを収める二つのIANAレジストリを提案するが、初版は編集途上であり、名前を根本原因の記録には変えない。
  • 自動化には、セッション、操作、要求主体、認可判断、対象パス、モジュール修飾identity、構造化ヒント、トランザクション結果、修復、再読出し、サービス結果を連結した証拠が要る。

自動化装置が invalid-value を受け取り、再試行を選ぶ。

整った判断に見える。名前は標準化され、規則にも書ける。しかしRESTCONFでは、同じタグがHTTP 400、404、406のいずれにも対応し得る。アクセス制御の場面では、保護対象が存在すること自体を明かさないため、サーバーが404と invalid-value を返すこともある。返答は正しい。すべてを語らないからこそ正しいのである。

2026年9月30日に公開された draft-ietf-netconf-error-registries-00 の意義は、この境界を見せる点にある。NETCONFワーキンググループの文書は「YANG Protocol Error List」と「YANG Protocol Error Identities」という二つのレジストリを提案した。YANG駆動の管理機構が増えるたび、実装者が複数のRFCから正典らしき一覧を再構成する状況を終わらせようとしている。

revision 00はStandards Trackを想定し、2027年4月3日に失効するInternet-Draftである。RFCでも、承認済みIANAレジストリでも、実装や相互接続の報告でもない。五ページの本文は統治面の着手であって完成ではない。

第一のレジストリは error-tag、有効な error-type と error-severity、error-info、説明、登録文書を持つ。第二はidentity名、該当する場合のbase identity、補足情報、登録文書を持つ。更新方針にはIETF Reviewが掲げられている。

一元化には明確な効用がある。表記ゆれを防ぎ、新しい値を見つけやすくし、定義を所有する文書を示せる。追加、変更、廃止、置換の手続も共有できる。これは語彙のための有用な制御面である。

一方、revision 00は機械が依存できる正典に必要な精度も示している。エラー一覧の先頭三フィールドの説明はまだ TBD である。初期内容はRFC 6241 Appendix Aから採るとしながら、本文に収録したのは in-use、invalid-value、too-big、missing-attribute、bad-attribute の五項目までだ。Appendix Aには、その後も access-denied、resource-denied、rollback-failed、data-missing、operation-not-supported、operation-failed、malformed-message などが続く。

identity一覧にも初版らしい編集痕がある。filter-unsupported、insufficient-resources、no-such-subscription は重複している。参照先RFCにあるidentityも一部抜けている。RFC 8639には stream-unavailable、suspension-timeout、unsupportable-volume があり、RFC 8641には cant-exclude、no-such-subscription-resync、on-change-unsupported、on-change-sync-unsupported、sync-too-big がある。登録方針の参照はRFC 5226だが、現在のBCP 26はそれを廃止したRFC 8126である。

これを将来の標準の欠陥と断定するべきではない。観察対象はあくまでrevision 00である。次版以降で重複排除、完全性、最新参照、フィールド定義を詰める余地がある。クライアントが私設表で黙って穴を埋めれば、草案が解消しようとした分散を再生産する。

仮に一覧が完全になっても、レジストリは一件の障害を説明しきれない。

RFC 6241のNETCONF <rpc-error> は単独コードではない。一つの応答が複数のエラー要素を持つこともある。各要素には、障害が生じた概念層、プロトコルタグ、重大度、データモデル固有または実装固有のアプリケーションタグ、対象ノードを示すXPath、人向けメッセージ、構造化情報を含められる。これらは重複ではなく、異なる証拠軸である。

RFC 8640のサブスクリプションエラーは階層を具体化する。filter-unsupported は一般タグ invalid-value に、insufficient-resources は resource-denied に、on-change-unsupported は operation-not-supported に、sync-too-big は too-big に、unchanging-selection は operation-failed に対応する。具体的なidentityは ietf-subscribed-notifications:no-such-subscription のようにモジュール修飾した error-app-tag で運ばれる。

その名前も操作から切り離せない。利用可能なbase identityは、失敗したRPCがサブスクリプションの確立、変更、削除、強制終了、再同期のどれかで異なる。確立と変更では、将来の要求を成功させるパラメーター候補を error-info に入れられる。RPCとヒントを捨て、単語だけ保存するのは証拠の劣化である。

unchanging-selection は意図的な圧縮をよく表す。RFC 8641では、選択が存在しないデータを参照する場合にも、受信者が読めないデータを参照する場合にも、このidentityを返し得る。後から認可が変わり、見えていた更新が見えなくなった場合にも使える。パス修正、権限取得、ポリシー変更後のフィルター再構築は別の処置だが、プロトコルは抽象と秘匿を守るため同じ安全な理由にまとめる。

no-such-subscription も同じ境界を守る。RFC 8639では、識別子が存在しない場合、別のsubscriberに属する場合、またはそのRPCが適用されないconfigured subscriptionの場合を同じ応答で扱える。要求者が得るべき結論は「この識別子にその操作はできない」であり、内部レコードの存在証明ではない。

insufficient-resources は別種の不確実性を圧縮する。publisherが要求されたsubscriptionを作れないことは示すが、足りないのがメモリ、CPU、帯域、キュー、実装上限、ポリシークォータのどれかは示さない。誰が容量を管理し、いつ戻り、どの負荷を譲らせるべきかも分からない。

つまり、レジストリは名前の権威であって、出来事の神託ではない。

最低限の受領記録はエラーより前から始まる。プロトコルとtransport session、RPC、request ID、認証された主体、認可判断を残す。対象datastoreとパス、一般タグ、モジュール修飾identityとbase、error-info、サーバーとモジュールのrevision、transaction結果を続ける。介入後には、誰が何を認めたか、状態を再読出しした結果、サービスで観測した結果を記録する。

この鎖は誤った等式を防ぐ。404は不存在の証明ではない。具体的なidentityは物理原因の証明ではない。次の要求が受理されても状態変更の証明にはならない。状態が変わってもサービス復旧の証明にはならない。

Heng Luの「最小初期仕様」は責任の配置を明確にする。標準化は多くの実装が共有できる最小語彙と拡張規則を定める。将来の判断は、その時点の事実を持つサーバー、運用者、サービス所有者に残す。レジストリは語彙の統治を適所に集めるが、現場の因果判断まで中央集権化しない。

現実層の区別も同じ規律を守る。operation-failed は記号である。存在しないノード、失われた権限、枯渇したキュー、不適切なパラメーターは異なる現実である。仕様が意図的に一つの記号で覆うこともある。記号を現実そのものとして扱えば、確実性を捏造する。

動くコードの優位は修復後の証拠を要求する。再試行を送ったこと、書込みが成功したことだけでは復旧ではない。状態を読み返し、意図したサービス結果を観測する必要がある。そこで初めて修復は命令から事実に変わる。

出典