Re: [YANG] errors

Martin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>> On Thu, Jan 24, 2008 at 08:41:49AM -0800, Andy Bierman wrote:
>>
>>> What if the DM writer wants to raise an existing standard error?
> 
> That's what I meant when I wrote that the raise-error is in addition
> to the standard errors.  I.e. nothing needs to be done in the DM for
> this scenario.
> 

except there has to be a CLR that no error-app-tag value can be
one of the standard error-tag values.  If the standard error-tag
values grow over time, this creating potential naming conflicts
with previously released error-app-tag values.

>>> Does there need to be a standard module for the NETCONF errors,
>>> added as an appendix?
>> Yes.
> 
> No, that's not possible with the way the error statement is done,
> since the identifier is error-app-tag.
> 
>>> 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.
> 
> Why can't the normal data-def stmts be used?  That would be the
> obvious choice if we want to do error-info.
> 

IMO, the document needs lots of work in the area of specifying
how all the data-def-stmt clauses apply to rpc/input, rpc/output,
and notification.  Now add error-info to that list.
The document has to specify exactly what every clause and sub-clause
means for each of these data definition types.

>>> (E.g., lock-denied has the <session-id> of the current lock owner.)
>>> If not, then I would rather leave it out.
>> Correct, this is needed. I think error-info is actually not much
>> different from in and out parameters where we also use standard YANG
>> constructs.
> 
> I agree.
> 
> 
> /martin
> 
> 

Andy

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