Summary

  • RFC 9984 defines reusable YANG groupings for UDP clients and servers, not a complete operational-state model. It explicitly exposes no protocol-accessible config false nodes.
  • A configured hostname still needs a resolution result, local port 0 still needs an operating-system choice, and a wildcard address still needs evidence that a process bound and listened. None of those runtime facts is supplied by the grouping itself.
  • Kent Watsen's contribution, shared with Alex Huang-Feng and Pierre Francois, is valuable partly because the common layer remains thin. Operators should preserve that portability while joining intent to applied socket, traffic and application receipts.

The audit that stopped one column too early

Imagine a change report with three green cells. The YANG payload validated. The configuration commit succeeded. The device's intended datastore now contains the requested UDP client. The report labels the service “running.”

That final label has no witness.

The remote address may be a hostname that has not resolved. The selected local address may no longer exist. Port 0 may have produced an ephemeral port that the report never captured. A server configured on a wildcard address may have failed to bind because another process already holds the port. Even a successful bind says nothing about whether a datagram crossed the interface or the application accepted it.

RFC 9984 does not promise those outcomes. Published in June 2026 on the Internet Standards Track, it defines ietf-udp-client and ietf-udp-server: two reusable YANG 1.1 modules for other data models to consume. The document says it follows the Network Management Datastore Architecture and then states the decisive limit: it defines no protocol-accessible nodes that are config false.

That sentence is not a missing feature disguised as small print. It tells the reader which layer is speaking. The RFC supplies configuration grammar. Running code must supply runtime evidence.

A grouping is not yet a node

The distinction begins before any socket is considered. RFC 7950 defines a YANG grouping as a reusable set of schema nodes, but it also says that the grouping statement is not a data-definition statement. By itself, it creates no node in the schema tree. Another module instantiates the material with a uses statement, and that module may refine or augment it.

This makes RFC 9984 a coordination artifact in a precise sense. It gives independent module authors the same names and types for a UDP contact surface without deciding every application-specific rule. The client grouping contains a mandatory remote-address, an optional remote-port, and optional local address and port leaves behind a local-binding feature. The server grouping supplies a list of local bind points. A consuming module decides where the reusable vocabulary becomes concrete.

There are therefore two receipts before configuration even reaches a device. One identifies the exact RFC module revision and registered namespace. The next records the consuming module, its uses location, enabled features, refinements, augmentations and schema fingerprint. “RFC 9984 supported” cannot replace either one. A product may ship the module file yet instantiate none of its groupings; two applications may use the same grouping while imposing different port requirements.

IANA's YANG Module Names registry makes the artifact stable. It lists the dated 15 June 2026 revisions of ietf-udp-client and ietf-udp-server, their namespaces and their prefixes. Registration answers which artifact has a recognized name. It does not answer whether a device loaded it, a service used it or a socket exists.

Four endpoint leaves, several unresolved decisions

The client grouping looks compact because it leaves some decisions to the right owner.

remote-address is mandatory, but its type permits an IPv4 address, an IPv6 address or a hostname. An address literal identifies a configured destination directly. A hostname introduces another actor and another clock: a resolver must produce an address under a particular view, cache and policy. RFC 9984 says the resolved address should be compatible with the local address family when one is configured. It does not add a leaf for the selected address, the resolver, the resolution time or the lifetime of the answer.

That omission is appropriate for a reusable grouping. Different consumers may resolve once, refresh periodically, retain several addresses or let an application library decide. It is dangerous only when an observability system displays the configured hostname as if it were the current peer tuple. The name is intent; the selected address is runtime state.

remote-port is neither mandatory nor given a default. The RFC advises a consuming module to refine it with a default when a well-known port exists, or make it mandatory when the application always needs one. That preserves reuse. It also means a validator cannot infer a complete destination tuple from the base grouping alone.

Local binding is optional. When the feature is enabled, local-port defaults to 0, explicitly allowing the operating system to choose any available port. Zero is therefore a request for delegated selection, not the port on the wire. A durable receipt must record both values: configured 0, effective port 49187, for example. If it stores only the second, it loses the operator's intent; if it stores only the first, it loses the fact that other systems can actually observe.

The local address can also be a wildcard. A wildcard expresses a binding policy, not a single interface address. Interface changes, address-family rules, container namespaces and operating-system behavior determine the actual exposure. A wildcard configuration should never be rendered as a factual list of listening addresses without a runtime observation behind it.

The server tree describes where to try

The server grouping requires at least one local-bind entry keyed by local address. It can represent IPv4 and IPv6 bind points together, different ports within one family, or wildcard addresses. The local port is again left for the consuming module to refine where appropriate.

The configuration is useful and testable. It can be validated for shape, type and application-specific requirements. But “valid” means the data satisfies the schema and constraints presented to the validator. It does not mean the operating system accepted the bind, the process retained the file descriptor, a firewall admits traffic, or the application is ready to interpret datagrams.

A port conflict makes the boundary obvious. The intended configuration may remain well formed while bind() fails. A process restart may pick a new ephemeral client port. A network namespace may contain fewer addresses than the management plane expects. A service can bind successfully and then crash. Each event changes a different state, and none requires the reusable grouping to be rewritten.

RFC 9984's security section is equally disciplined. The modules by themselves expose no writable nodes, read-only state nodes or RPCs. Modules that reuse the groupings inherit the duty to describe their own security considerations. Address and port fields can be privacy-sensitive, so the answer is not to publish every socket detail to every reader. It is to collect bounded evidence with access appropriate to its operational purpose.

NMDA supplies the missing grammar

RFC 8342, which lists Kent Watsen among five authors, formalizes the space between a desired value and the value a device is using.

<intended> contains configuration after transformations and represents what the system attempts to apply. Applied configuration is the part actively in use. System state covers transient runtime information and statistics. <operational> combines applied configuration and system state. The architecture even tells a client how to test part of the join: compare <intended> with the config true subset of <operational> to see how much intended configuration is currently in use.

That comparison matters because application is not instantaneous or guaranteed. Hardware, software, protocols, missing resources and transformation logic can separate the two views. RFC 8342 also recognizes remnant configuration that can persist while resources such as network connections, memory allocations or file handles are being removed.

RFC 9984 does not populate this operational side for a UDP socket. A consuming model or implementation can add it, but the base grouping neither requires nor forbids one universal design. This is the correct division of labor: the shared vocabulary remains small, while the actor that knows the runtime environment provides the evidence that only it can know.

Kent Watsen's place in a collective design

The official IETF Datatracker profile captured for this article on 2 September 2026 describes Kent Watsen as an industry expert in network management and security. It lists current chair and reviewer roles, and records RFC 8040, RFC 8342 and RFC 9984 among 21 RFCs at that time. The count and roles are a dated snapshot, not permanent status.

RFC 9984 is collective work. Alex Huang-Feng and Pierre Francois appear with Watsen as document authors, and the embedded module contact blocks name Huang-Feng and Francois. The acknowledgements credit a wider review group. No source supports describing Watsen as the sole inventor, implementer or operator of the model.

His relevance to this article is more specific. Across the Datatracker record, RESTCONF, NMDA and the UDP grouping document sit in the same long project: making management interfaces precise enough for independent systems to exchange structured intent. Precision includes knowing when a model stops. The RFC is stronger because it does not pretend to know which socket an unknown future application will create.

Heng Lu's Running-Code Primacy gives that restraint an operational interpretation. A document matters when it helps systems run; publication cannot substitute for execution. His Minimum Initial Specification principle adds the architectural reason for keeping the common layer thin. Stable endpoint fields and reusable groupings belong in the shared specification. Resolver policy, socket lifecycle, process supervision, traffic evidence and application success can remain local unless interoperability truly requires them.

The boundary also exposes an agency problem. A management platform is rewarded for fast, clean configuration compliance. The application owner bears the loss when no service is available. If the platform promotes “commit accepted” to “service running,” the easier metric acquires authority over the actor that carries the operational risk.

Six receipts for one honest status

An operator can preserve the thin standard and still build a complete chain of evidence.

The artifact receipt records the RFC module revision, namespace, IANA reference and checksum. It proves which common vocabulary is available.

The instantiation receipt records the consuming module, uses path, features, refinements, augmentations and schema version. It proves which concrete configuration contract was built from that vocabulary.

The intent receipt records the accepted change, relevant transformation, <intended> snapshot, actor and time. It proves what the system was asked to apply.

The runtime receipt records the process or service instance, resolution result, effective local and remote tuples, address family, bind or connect result, socket creation time and close reason. It proves what the operating system and process established. Sensitive fields can be access controlled, truncated or retained briefly; evidence quality does not require indiscriminate publication.

The traffic receipt records bounded counters and observations: first and last datagram, packets and bytes by direction, drops, relevant socket errors and measurement window. It proves activity at a boundary, not payload meaning.

The application receipt records the protocol-specific outcome: authenticated peer, accepted request, valid response, transaction result or health check. Only the application can define that final claim.

These receipts permit honest intermediate states. A configuration may be valid but not applied. A socket may be bound but idle. Datagrams may arrive while authentication fails. An application may be healthy on one effective address and absent on another. None of these states makes RFC 9984 wrong. They show why the model and the runtime must remain separately named.

Sources