要約

  • RFC 10009 は、HTTP クライアント URI、許可バージョン、任意の TLS とプロキシ、サーバー側 HTTP 設定、待受スタックの組み合わせを表す再利用可能な YANG 1.1 材料を提供する。
  • 三つのモジュールは typedef と grouping を定義するだけで、単独ではプロトコルから到達可能なノードを作らない。記入済みのモデルは設定意図の証拠であって、待受、認証、要求受理、効果の証明ではない。

RFC 10009 の役割は接続前にある。ietf-http-client は URI、ローカル方針で制限された HTTP バージョン、クライアント TLS 材料、proxy CONNECT の選択を表現できる。ietf-http-server はサーバースタックの HTTP 部分を表し、別の便利な grouping が TCP、TLS、または QUIC/UDP と組み合わせる。これにより層は一つの管理画面に並べられるが、一つの稼働事実にはならない。

クライアント側の境界は明瞭だ。必須なのは uri だけで、scheme と host が必須の子である。URI の scheme と authority は下位のトランスポート層に関する情報を持つ。protocol-versions は設定が許すバージョン、読み取り専用の supported-versions は設定と別に実装が対応するバージョンを表す。任意の TLS パラメータはクライアント識別とサーバー認証の材料を、プロキシ項目は経由先を記す。これらは DNS 応答、TCP/QUIC 経路、証明書判断、アプリケーション応答を観測する値ではない。TLS パラメータがなければその設定では TLS 接続は不可能だが、あれば特定の相手に到達し受け入れられるという約束にもならない。

サーバー側も同様に狭い。HTTP server grouping は HTTP 部分だけを設定し、TCP や TLS の設定はしない。listen-stack grouping は HTTP over TCP、TLS、QUIC を組み立てるが、それぞれの下位 grouping を残す。server-name、許可バージョン、feature による任意の簡易 Basic ユーザー情報は設定選択にすぎない。プロセスが待受中であること、80/443 が bind されたこと、相手の認証、パスワード管理、アプリの操作許可を示さない。整ったモデルの後にも失敗点はある。

決定的なのは、RFC 10009 の三つのモジュールが再利用可能な型または grouping を定義するだけで、単独ではプロトコル到達可能なデータノードを定義しない点である。消費するモジュールがノードを instantiate しなければならない。実行前から、再利用モデルと消費者が実際に設計したデータノードという二種類の証拠がある。その後に、許可済み管理書込み、配備版、bind 済み待受、トランスポートと相手、HTTP 交換、アプリ受理、観測効果が続く。「設定済み」という一語は、意図を実行結論にすり替える。

設定の権限はサービスの権限の手前で止まる

安全性の節もこの分離を守る。grouping-only モジュールの影響は、それを使うモジュールに依存する。NETCONF と RESTCONF による管理には安全な輸送と相互認証が必要であり、NACM は管理ユーザーが読書きできる操作と内容を制限できる。これは管理面を誰が扱えるかの答えであり、HTTP クライアントの業務権限やサービス配信の証明ではない。

IANA が維持する HTTP バージョン typedef も過大評価すべきではない。レジストリは共通語彙を提供し、実装は能力を公開できる。しかし、特定設定で有効化されたこと、相手とネゴシエートされたこと、中間者に受理されたこと、アプリで有用だったことを示さない。レジストリは参照、能力はローカル宣言、実行中の交換は別の証拠である。

これは IETF 要件ではなく編集上の読み方である。Heng Lu の最小初期仕様は、共通層を小さく保つ意味を示す。部品を組み合わせ、後の選択を局所に残すためだ。稼働コードの優位は実務の検証を示す。サービスが動いたという主張は、先のモデルだけでなく、照合された実行記録に依拠する。