On Sun, Mar 15, 2026 at 9:15 PM James Cumming (Nokia) <james.cumming= [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. > > This is not a special case for action. Lots of RPCs can encounter errors after starting to return data. > 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. > > Our server has supported --return-error-with-data for many years. If the back-end throws any errors, the server remembers them, finishes the data reply so it is well-formed XML, and adds <rpc-error> elements at the end as needed. I know this violates the XSD in RFC 6241 but so what. Andy 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 > > _______________________________________________ > 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]
