Re: is a warning really an error?

[Andy Bierman <ietf@andybierman.com>]

Kent Watsen wrote:
> All,
>
> The spec specifies that an <rpc-error> can be returned to report a
> warning, but warnings generally do not terminate processing while errors
> do and <rpc-error> are returned whenever a "request cannot be completed
> for any reason"

warnings cannot be returned with <ok/>,
but they can be returned with <data>.

The spec is sort of silent on the use of warnings,
mostly because none are defined in the RFC.

But the XSD for <rpc-reply> is correct, and there is no
restriction on the setting of the error-severity field.
I think it is okay to use 'warning' instead of 'error'
for a pre-defined error condition, especially if the
agent is ignoring or correcting for the error.

It is not really okay to define new error-tag values,
because the error-app-tag should be used instead,
added to existing errors.


> To highlight the conflict, consider:
>
> 1. Is it possible for <commit> to return a warning using <rpc-error>
> without signaling that the transaction failed?

If the reply contains only warnings and no errors,
then it succeeded, but maybe not as intended.

> 2. Is it possible for <edit-config> to return a warning using
> <rpc-error> without signaling that the error-options (stop-on-error,
> continue-on-error, rollback-on-error) were ignored?
>
>
> Given this ambiguity, should "warning" should be removed from the spec?

no -- it is not compliant to RFC 4741 to ignore the error-option parameter.
A spec always has room for more clarifications, so I guess it
could be more clear that if all the error-severity values
are 'warning', then the operation did not fail.


> Thanks,
> Kent

Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>