Re: [YANG] errors

Martin Bjorklund wrote:
> Hi,
> 
> We have been talking about adding two new statements related to
> error generation to YANG.
> 
> The first statement is 'error'.  It is used to define a named error.
> The second statement is 'raise-error'.
>....
> The errors defined for an rpc would be in addition to the standard
> errors defined in rfc4741.
> 

The phrase 'in addition' concerns me.

I think you mean that an error MUST use one of the existing
error-tag values from RFC 4741, but the other fields specified
in error-stmt will be used in an <rpc-error> generated for the
particular error condition.  IMO, this is too flexible.

There is a balance between multi-vendor interoperability
and single-vendor-flexibility that must be carefully considered
when developing a standard.  IMO, it would drastically harm
interoperability if the <rpc-error> mechanism turned into
just another proprietary hack (I mean 'vendor-specific content' ;-)
within NETCONF.

What does it mean for interoperability if vendors override an error defined
in RFC 4741 or the Notifications RFC, with different error-severity,
or error-message?  What if they ignore some/all of the standard errors,
and use their own proprietary set (because it's better of course ;-)

IMO, the structured error return codes in NETCONF represent an important
advancement away from screen-scraping CLI.  It is important that this
is not compromised.  A vendor is not compliant with RFC 4741
unless all the errors are generated exactly as specified in the spec,
regardless of what the YANG draft says.

I think it needs to be clear in the draft that the fields defined
by standard errors cannot be changed, and <rpc-error> behavior
defined in the standard cannot be changed (e.g., send the
acme-lock-denied error *instead* of the standard lock-denied error,
which uses a different error-tag value, or does not include the
<session-id> error-info).

> Grammar:
> 
>     error-stmt = error-keyword sep error-app-tag-str optsep "{"
>       ; error-app-tag-str is an identifier 
>       error-tag-stmt stmtsep
>       [error-message-stmt stmtsep]
>       [error-severity-stmt stmtsep]   ; default is error
>       [description-stmt stmtsep]
>       [reference-stmt stmtsep]
>     "}"
> 
>   raise-error error-app-tag-ref-str stmtsep
> 

What if the DM writer wants to raise an existing standard error?
Does there need to be a standard module for the NETCONF errors,
added as an appendix?

Notably missing from the error-stmt is definition of any error-info data.
An open issue is whether there is some simple mechanism for defining
error-info, other than full-blown data-def-stmt, to define error leafs.
(E.g., lock-denied has the <session-id> of the current lock owner.)
If not, then I would rather leave it out.

> 
> Comments?
> 
> 
> /martin
> 
> 

Andy

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang