摘要

  • RFC 10009 为 HTTP 客户端和服务器提供可复用的 YANG 1.1 材料：客户端 URI、允许的 HTTP 版本、可选 TLS 与代理参数，以及服务器的 HTTP 配置和便捷监听栈组合。
  • 这三个模块只定义 typedef 和分组，本身不定义可通过协议访问的节点。填好的模型证明配置意图，不能证明端口已绑定、请求被接纳、身份已验证或业务效果已发生。

RFC 10009 的价值恰好在连接发生之前。ietf-http-client 分组可以表达 URI、受本地策略限制的 HTTP 版本、客户端 TLS 材料和通过代理连接的选择。ietf-http-server 描述服务器协议栈中的 HTTP 部分；另一个便捷分组把 HTTP 与 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。监听栈分组可以给出 HTTP over TCP、TLS 或 QUIC，但每一种仍保留相应的下层分组。server-name、允许版本和由 feature 控制的简易 Basic 本地用户库是配置选择，不是运行事实。它们不证明有进程在监听、不证明 80 或 443 端口已绑定、不证明对端认证成功，也不证明密码治理充分或应用批准了某项操作。模型完备并不等于后续链路没有失败。

最重要的一句是：RFC 10009 的三种模块提供可复用类型和分组，单独使用时没有任何可通过协议访问的数据节点。必须有消费它们的模块来实例化节点。因此，在运行开始前已经存在两份不同证据：可复用模型与消费者真正定义的数据节点。之后还要依次看到已获许可的管理写入、部署版本、绑定的监听器、传输与对端结果、HTTP 交换、应用准入和观察到的效果。把它们统称为“端点已配置”，就是把意图误写成运行结论。

配置权限止于服务权限之前

安全章节保留了同样的边界。分组模块的安全含义取决于使用它们的模块。NETCONF 与 RESTCONF 管理要求安全传输和相互认证；NACM 可以限制某个管理用户能读取或修改的操作和内容。这些控制的是管理平面上的读写权限，不是任何 HTTP 客户端的业务授权，也不是服务已经交付的证明。

IANA 维护的 HTTP 版本 typedef 也不应被放大。登记表能提供共同词汇，实现可以公开自身能力；这都不能证明某版本已在具体配置中启用、与具体对端协商、被中间设备接受或给应用带来结果。登记表是参照，能力是本地声明，运行中的交换才是另一类证据。

这是一项编辑性解释，并非 IETF 规定。Heng Lu 关于最小初始规范的论述说明了为何共同层应保持克制：它让组件可组合，把后续选择留给本地。其运行代码优先的观点给出了检验方法：服务确实发挥作用，只能由被核对过的执行记录证明，不能由之前的模型单独证明。