Hi James, In my opinion, It would depend on, if we want it to be asynchronous/synchronous, if the rpc consists of a yang action, which takes some execution time(eg: a file download), it might not be a good idea to have it synchronous/blocking as the client/transport layer could timeout, in such cases, we could have the rpc-reply sent out immediately followed by a notification based on the actual result.
Regards, Deepak From: James Cumming (Nokia) <[email protected]> Sent: Monday, March 16, 2026 9:44 AM To: NETCONF WG <[email protected]> Cc: NETMOD WG <[email protected]> Subject: [netmod] YANG actions in progress over NETCONF 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). Thanks
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
