Re: [YANG] errors

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> 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. 
> > 
> > Why?
> > 
> > 
> 
> error lock-denied {
>    error-tag operation-failed;
> }
> 
>   ...
>   raise-error lock-denied;
> 
> 
> Is this raise-error for the standard lock-denied or for the
> vendor error called lock-denied, defined in the same module?

The idea was (I think it came from you :) that the identifier for the
error clause is error-app-tag.  So the above would be in XML:

  <rpc-error>
    <error-tag>operation-failed</error>
    <error-app-tag>lock-denied</error-app-tag>
  </rpc-error>

Thus, no name clash.

Side note: the error-app-tag is defined as a string in rfc4741, but
IMO is should have been a QName.  If it was, all error-app-tags would
be local per namespace, so the above would be:

    <error-app-tag xmlns:foo="...">foo:lock-denied</error-app-tag>

/martin

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