Subject: [netmod] YANG 1.1 new issue: add exception statement

From: [email-masked]
Date: Mon, 28 Apr 2014 17:45:34 +0800

Hi all,
      I suggest add 'exception' statement to make 'error-app-tag' and 
'error-message' can be reused and make it possible to express multi 
'error-app-tag' or 'error-msg'.
      'exception' statement can be mapped to 'rpc-error'element in 
NETCONF.
      exception statement's sub statement:
                 +---------------+-------------+
                 | substatement  | cardinality |
                 +---------------+-------------+
                 | description   | 0..1        |
                 | error-app-tag | 0..1        |
                 | error-message | 0..1        |
                 | reference     | 0..1        |
                 +---------------+-------------+
      For example:
      exception  foo {
           error-app-tag "abc";
           error-message "This is just a example";
      }

      and add 'throws' statement as must's substatement.
 
      For example :
      must "a > b or a < 1500" {
           throws foo;
      }
 
      btw: 'throws' statement can be used to declare a exception may be 
thrown.

      if a 'must' expression may throw multi exceptions, the example is 
listed below:
 
      must "a > b or a < 1500" {
            throws foo1;
            throws foo2;
      }
 
      If a exception statement has no error-app-tag and error-message, it 
means any exception may be thrown.

I also suggest add 'throws' ,'error-app-tag' and 'error-message' 
statements to 'rpc' statement, it can indicate which exception may be 
thrown.

User who execute rpc operation can be easy to handle 'rpc-error'.
      rpc's subsatatment:
                 +--------------+-------------+
                 | substatement | cardinality |
                 +--------------+-------------+
                 | description  | 0..1        |
                 | grouping     | 0..n        |
                 | if-feature   | 0..n        |
                 | input        | 0..1        |
                 | output       | 0..1        |
                 | reference    | 0..1        |
                 | status       | 0..1        |
                 | typedef      | 0..n        |
                 | error-app-tag| 0..1        |
                 | error-message| 0..1        |
                 | throws       | 0..n        |
                 +--------------+-------------+
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2014 07:27:50 -0700

Hi,

This seems like a lot of indirection to save 1 line.
The reader has to go find the exception-stmt.

It does make me wonder how many developers are using error-app-tag?
Do you use the values hard-wired from NETCONF and YANG?  Do you use
your own error-app-tag values?  What do you do when an error has the
standard error-app-tag instead of the vendor tag? Did you merge your
classification system with the standard or do they step on each other?

IMO error-app-tag extensibility is not well thought-out.
It is not multi-vendor interoperable if vendors define their own values.
The error-message leaf is not really intended to provide any
interoperability
value, so it is OK that it is vendor-specific.

Andy

On Mon, Apr 28, 2014 at 2:45 AM, <[email-masked]> wrote:

> Hi all,
>      * I suggest add 'exception' statement to make 'error-app-tag' and
> 'error-app-tag' or 'error-msg'.*
> *      'exception' statement can be mapped to 'rpc-error'element in
> NETCONF.*
> *I also suggest add 'throws' ,'error-app-tag' and 'error-message'
> thrown.*
> *User who execute rpc operation can be easy to handle 'rpc-error'.*
>       rpc's subsatatment:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Apr 2014 17:08:11 +0200

On 28 Apr 2014, at 16:27, Andy Bierman <[email-masked]> wrote:

> The error-message leaf is not really intended to provide any interoperability

I think both error-app-tag and error-message would be much more useful if they could be parametrized. Schematron is really great in this respect, e.g.

   Duplicate leaf-list entry "<sch:value-of select="."/>".

However, I can’t think of a syntax suitable for YANG.

Lada

>       I suggest add 'exception' statement to make 'error-app-tag' and 'error-message' can be reused and make it possible to express multi 'error-app-tag' or 'error-msg'. 
>       'exception' statement can be mapped to 'rpc-error'element in NETCONF. 
>       btw: 'throws' statement can be used to declare a exception may be thrown. 
> 
>       if a 'must' expression may throw multi exceptions, the example is listed below: 
>       
>       If a exception statement has no error-app-tag and error-message, it means any exception may be thrown. 
> 
> I also suggest add 'throws' ,'error-app-tag' and 'error-message' statements to 'rpc' statement, it can indicate which exception may be thrown. 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Apr 2014 08:26:17 -0700

On Mon, Apr 28, 2014 at 8:08 AM, Ladislav Lhotka <[email-masked]> wrote:

> I think both error-app-tag and error-message would be much more useful if
> they could be parametrized. Schematron is really great in this respect, e.g.
>
> However, I can't think of a syntax suitable for YANG.
>
>
I would like to keep YANG as simple as possible.

The problem with error-app-tag is that the classification system is
a flat list of arbitrary strings.  Yuma* has one of these arbitrary
classification
systems.  The handful of ad-hoc standard error-app-tags will over-ride these
values.

You do re-raise the point of a structured error-message; e.g., sprintf w/
parameters
from elsewhere in the <rpc-error>.  (Make sure this is on the issue list.)

IMO, error-app-tag needs to be a leaf-list, not a leaf.
That would allow multiple classification systems -- vendor + standard.

(If we were really learning from the SMIng/EoS disaster, we would also
be chartering YANG 1.1 +  NETCONF 1.2 + RESTCONF 1.0 as a coordinated
effort.)

Lada
> > ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential
> and is intended for the exclusive use of the addressee(s).  If you are not
> an intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
>  If you have received this mail in error, please delete it and notify us
> immediately.
> >
> >
> >
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Apr 2014 20:55:13 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> I think both error-app-tag and error-message would be much more useful if they
> could be parametrized.

Not error-app-tag.  It is supposed to be a static token.

> Schematron is really great in this respect, e.g.
> 

We're using XPath expressions (elsewhere) embedded within curly
brackets.  Something like this:

  list interface {
    key name;
    must "mtu >= 1500" {
      error-message
        "Interface {name}'s mtu is {mtu}, must be >= 1500";
    }
    ...
   }

The string with the curly brackets is evaluated as an XPath expression
and converted to a string.  This string is substituted instead of the
curly bracket expression.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Apr 2014 21:27:38 +0200 (CEST)

> IMO error-app-tag extensibility is not well thought-out.

+1

I always thought it should have been a QName.

And I agree it should have been a leaf-list.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Apr 2014 21:49:12 +0200 (CEST)

Hi,

Added as Y43.

/martin

[email-masked] wrote:
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s).  If you are not an intended
> recipient, any disclosure, reproduction, distribution or other dissemination or
> use of the information contained is strictly prohibited.  If you have received
> this mail in error, please delete it and notify us immediately.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Apr 2014 21:49:42 +0200 (CEST)

> from elsewhere in the <rpc-error>.  (Make sure this is on the issue list.)

Added as Y44.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Apr 2014 22:00:35 +0200

> curly bracket expression.

IMO this is worth considering, shall we make it an issue?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Apr 2014 22:03:36 +0200

> I always thought it should have been a QName.

Perhaps an identity, similar to the exception classes in Python?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Apr 2014 13:05:58 +0200 (CEST)

> IMO this is worth considering, shall we make it an issue?

I thought I did, turned out I forgot to checkin.  Now done. Y44.

/martin