Hi James, On Mon, Mar 16, 2026 at 5:15 AM James Cumming (Nokia) <[email protected]> wrote: > > Following on from some of the error handling discussion in the in-person > NETCONF session today at IETF125, I’m looking for some feedback on what the > working group feels is the expected behaviour of the following situation. > > An action running in NETCONF can either reply with an rpc-reply statement > (implying the action was successful) or an rpc-error statement (mutually > exclusive). The implication here is that the server knows whether the action > was successful or not before it responds. > > Has anyone encountered the situation where the server believes it can fulfil > the action and starts doing so (perhaps a long running output or an output > that returns in chunks) and subsequently encounters an error. In this > situation the rpc-reply would have started and so an rpc-error wouldn’t be > returned. > > If this is indeed a gap in the specification, should we look to close it in > NETCONF 2.0? This is currently sitting in the YANG 1.1 spec [hence the > NETCONF/NETMOD cross-post] (including the NETCONF/XML part of it but I > believe this is on Kent’s list to strip out).
It is a common use that you describe. When I was at Cisco we did different implementations of the error behavior for RESTCONF. First we actually just blurted out an rpc-error in the midst of an ongoing rpc-reply and then terminated the connection. The intention was that it gives the user some hint on what went wrong. This has the consequence that the resulting data is most probably not valid XML or JSON, since the current tree isn't closed in a valid way. Later we modified this by removing the emit of the rpc-error and just cut the connection, with the reasoning that this is a programmatic interface, and the error disrupts more or at least doesn't help a program to recover. This is the current method AFAIK. Also note that RFC 8639 recommends to just cut the connection if NACM rules are changed to deny access for a dynamic subscription, no error reporting (in the subscription). -- Per > Thanks > > _______________________________________________ > netconf mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
