Summary

  • RFC 10009 supplies reusable YANG 1.1 material for HTTP clients and servers: a client URI, selected HTTP versions, optional TLS and proxy parameters, plus server-side HTTP configuration and a convenience listen-stack composition.
  • Its modules define a typedef and groupings, not standalone protocol-accessible nodes. A completed model is evidence of intended configuration, not proof that a service bound, authenticated, admitted a request or produced an effect.

RFC 10009 is deliberately useful before a connection is made. Its ietf-http-client grouping can record a URI, a policy-constrained list of HTTP versions, TLS client material and proxy CONNECT details. Its ietf-http-server material can record the HTTP portion of a server, while a separate convenience grouping assembles HTTP with TCP, TLS or QUIC/UDP components. That decomposition lets a consuming model present one coherent configuration surface without pretending that all layers are one fact.

The client side illustrates the restraint. The only mandatory part of the client grouping is uri, whose mandatory descendants include the scheme and host. The URI's scheme and authority carry lower-layer transport information. A protocol-versions list says which versions local configuration allows; a read-only supported-versions list says what an implementation supports independently of that configuration. Optional TLS parameters name client identity and server-authentication material, and optional proxy fields name a route through a proxy. None of these fields observes a DNS answer, proves a TCP or QUIC path, confirms a certificate decision, or records an application response. If TLS client parameters are absent, RFC 10009 says TLS connections are not possible under that configuration; if they are present, it still does not say a particular peer will be reached or accepted.

The server side is equally precise. The HTTP server grouping covers the HTTP part of a protocol stack, not TCP or TLS configuration. Its convenience listen-stack grouping offers HTTP-over-TCP, HTTP-over-TLS and HTTP-over-QUIC compositions, each retaining its lower-layer grouping. server-name, permitted protocol versions and an optional, feature-gated simple Basic-auth user store are configuration choices. They do not establish that a process is listening, that port 80 or 443 actually bound, that a peer authenticated, that a password lifecycle is adequate, or that an application authorised an action. A server can possess an elegant model and still fail at any one of those later steps.

The most important sentence is easy to miss: all three RFC 10009 modules define reusable types or groupings and, by themselves, define no protocol-accessible nodes. A consuming module has to instantiate the material. That means there are at least two different records before runtime begins: the reusable model and the consumer's actual data-node design. Then come further records: a management change accepted under its own access rules, a deployed revision, a bound listener, a transport/peer result, an HTTP exchange, application admission and an observed effect.

Collapsing them into “the endpoint is configured” converts an intention into an unsupported operational conclusion.

Configuration authority stops before service authority

RFC 10009's security section preserves this separation. It says the implications of these grouping-only modules depend on the modules that use them. YANG management protocols such as NETCONF and RESTCONF require a secure transport and mutual authentication; NACM can constrain which management operations and content a user may access. Those controls answer who may alter or read a management surface. They do not grant a client permission to invoke every application operation, prove an HTTP service's safety, or turn a saved configuration into delivery.

The same discipline applies to the IANA-maintained HTTP-version typedef. The registry can keep a portable vocabulary current, and an implementation can expose what it supports. Neither fact proves a version was enabled in a particular configuration, negotiated with a peer, accepted by an intermediary or useful to an application. A registry is a reference; a supported capability is a local statement; a running exchange is separate evidence.

This is an editorial interpretation, not an IETF requirement. Heng Lu's account of minimum initial specification helps explain why the common layer is small: it makes components composable while leaving later decisions local. Running-code primacy supplies the practical test. The authoritative claim that a service worked belongs to the reconciled execution record, not to the earlier model alone.