Re: [YANG] errors

Andy Bierman <ietf@andybierman.com> wrote:
> 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 meant that if an rpc has one raise-error clause, it doesn't mean
that the standard error messages cannot be generated.  It just means
that in addition to the normal error messages (e.g. missing-element),
these DM-specific errors can also occur.

> I think you mean that an error MUST use one of the existing
> error-tag values from RFC 4741

Yes that was the idea, although I forgot to mention it.

> 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?

You are right.  [checking rfc4741...] Hmm.  An rpc-error MUST include
error-tag.  The list of error-tags is defined in rfc4741.  For each
such tag, the corresponding error-severity is defined.  All tags have
error-severity 'error'.  Conclusion: error-severity 'warning' can
never be generated. !!?!?!

One other thing.  The error-message is not defined by rfc4741, so it
should be ok for a DM to define one.

> 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).

Agreed.  The idea is to provide more, specific, info, in addition to
the standard messages.  The idea is not to change the standard
messages.

/martin

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