Summary

  • RFC 10011 standardises YANG configuration for RESTCONF clients and servers, including Call Home. A configured peer, listener or endpoint is a desired arrangement, not proof that a particular peer has connected or been trusted.
  • RFC 8071 reverses the TCP initiator in Call Home while retaining the RESTCONF server/client roles. The receiving client still has to validate an independently expected host key or certificate before treating the transport as a session.
  • Operators need separate evidence for intent, TCP arrival, peer-identity validation, authenticated RESTCONF session and a locally authorised management action. Combining them creates an attractive but unsafe green light.

The direction of a socket is a poor identity claim

Call Home solves a practical deployment problem. A device can be behind NAT, receive an address that is not published in a mapping service, sit behind a firewall that admits no inbound management access, or deliberately expose no management port. RFC 8071 lets the network element begin the TCP connection to a management client. RFC 10011 supplies configuration models for the RESTCONF side of that relationship.

That inversion is operationally useful because it changes reachability. It does not change who has to prove what.

The ordinary visual cue is misleading. A controller listens; a connection appears; an inventory entry was configured to call home; therefore the arriving peer must be that inventory entry. At most, the cue establishes that something reached a listener. Source address, port, timing and a matching configuration row can improve a hypothesis. None is the independent identity proof that the Call Home security model requires.

RFC 8071 is unusually clear about the narrowness of the reversal. At TCP, the network element acts as the client that initiates the connection. At the secure-transport and RESTCONF layers, it remains the server and the management system remains the client. The role labels have not migrated upward simply because the first packet travelled in the unexpected direction. That is why a dashboard which labels every inbound Call Home connection “device authenticated” is making a claim the layering does not support.

A model carries desired state; it does not manufacture observed state

RFC 10011 belongs to a family of YANG modules for trust material, keys, TCP, SSH, TLS, HTTP, NETCONF and RESTCONF. Its contribution is valuable precisely because it makes a configuration shape inspectable: a client and server can have named connection structures, transport choices and Call Home arrangements that another implementation can understand.

But a YANG configuration is a statement of desired state. Even when accepted by a local datastore, it does not prove that the process has opened a listener, that a route exists, that a remote process is trying the endpoint, that a TLS handshake completes, or that the presented credential belongs to the peer the operator intended. NMDA’s distinction between configuration and operational state matters here. It is not a database nicety. It prevents a change plan from masquerading as a connection fact.

The right evidence chain has at least four records:

  1. A desired-state record identifies the expected peer, transport, listening policy and trust material.
  2. A transport record shows a particular TCP acceptance attempt, with time and local listener context.
  3. An identity-validation record shows the presented host key or certificate was checked against a preconfigured issuer or pinned value and an independently expected identifier.
  4. A session record shows RESTCONF authentication and the negotiated management session, distinct from any later request to alter configuration.

An operation can be healthy at one record and fail at the next. A correct desired configuration may have no remote reachability. A TCP connection may arrive with a certificate that fails validation. A valid secure transport may have no usable RESTCONF credentials. A usable RESTCONF session may contain a request that has not been authorised under the operator’s own change policy. The chain is not pedantry; it is how an operator avoids assigning the wrong consequence to the right-looking signal.

Call Home requires an expected identity before the connection tells its story

RFC 8071 requires the management client to validate the server’s presented host key or certificate. It allows certificate-path validation to a preconfigured issuer or comparison with a previously trusted or pinned value. Where a certificate path is used, the client also needs an identifier it knew before the connection attempt. It must associate credentials used for client authentication with the presented server key or certificate.

Those requirements answer a subtle problem created by reverse connection setup. A TCP initiator can choose a route to a listener. It cannot choose its way into an identity merely by arriving there. The relying system needs an expected reference against which the received evidence is checked. A name learned only from the arriving peer is not the same kind of evidence as one established before the arrival.

That distinction is especially important when the controller carries secrets or credentials. RFC 8071 warns that a broadly issuing third-party certificate authority combined with a shared-secret authentication scheme can create a path in which a client sends a secret to another server bearing the same identity string. The lesson is not that Call Home is prohibited. It is that the trust relationship has to be explicit enough to resist a superficially plausible arrival.

The final jump—from session to action—is local

RESTCONF is an HTTP-based interface to YANG-defined configuration and state data. It supplies protocol machinery. It does not decide whether a particular operator should approve a routing, access, service or credential change at a particular time.

That is where Heng Lu’s minimum-specification discipline is practical rather than decorative. The common layer may define a deterministic way to describe a connection and verify a certificate chain. The local layer decides which device identities are expected, which issuers are acceptable, what a listener may expose, which credentials map to which service account, which requested operations require another approval, and which rollback evidence is sufficient.

An organisation may choose a fully automated path for an isolated lab environment and a multi-party approval path for a production edge. RFC 10011 does not settle that disagreement, and it should not. Its value is that both arrangements can use a shared technical vocabulary without pretending that the vocabulary has become a sovereign policy engine.

A restrained operational test

For each Call Home event, retain the expected peer identity, the configuration revision that made the listener possible, the exact accepted transport tuple, the validation outcome, the RESTCONF authentication outcome, the requested operation and the independent authority record for that operation. Give each record its own timestamp and owner.

This makes investigation less theatrical. “The device called home” becomes a question with testable parts. Did the configured process attempt the connection? Was the accepted connection bound to the expected certificate or key? Did the RESTCONF session authenticate under the right account? Did the requested change match an approved scope? Was the before-state captured and rollback still possible?

The connection has then earned a precise meaning. No more, but no less.