Subject: [netmod] strawman REJECT Y43 add exception statement

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 1 Jun 2014 17:20:17 +0200

It is unclear how valuable reusable but somewhat exceptions in real
data models are.

Speak up by June 10th if you disagree with this strawman proposal.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: [email-masked]
Date: Thu, 5 Jun 2014 14:21:26 +0800

Hi,
  If many 'must' statements report the same error-app-tag and 
error-message, 
you can use 'exception' statement to define one exception, and throw this 
exception in 'must' statements,
otherwise, you must define the same error-app-tag and error-message many 
times in every 'must' statement.

In real world, a server usually defined many general error codes, and 
app(module) would use these error codes 
to report error. 'exception' statement can be used to define the 
information of these error codes.

It's also very useful that a rpc can declare its exception. NETCONF is a 
programmable interface,  if a rpc declared its 
exceptions , APP who use NETCONF as programmable interface can catch these 
exception and do something it want to do,
such as printing the error message, changing the request and resend to 
server, invoking a notification,etc.

/frank

"netmod" <[email-masked]> 写于 2014-06-01 23:20:17:

> Juergen Schoenwaelder <[email-masked]> 
> 发件人:  "netmod" <[email-masked]>
> 
> 2014-06-01 23:20
> 
> 请答复 给
> Juergen Schoenwaelder <[email-masked]>
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> 主题
> 
> [netmod] strawman REJECT Y43 add exception statement
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--------------------------------------------------------
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: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 10:33:13 +0200

Hi,

I think the proposal is well described and understood.

The question is more whether this is a proposal that meets the YANG
1.1 goals or whether this is perhaps a proposal to consider for YANG
2.0. The WG charter clearly says that we are producing "a maintenance
release of the core YANG specification" and hence we should stay away
from adding new features unless we have strong evidence that there is
a real shortcoming that has surfaced in practice.

So it would be useful to hear from those who have experience with lots
of data models to what extend the lack of reusable exceptions has
caused them serious trouble.

The initial assessment that led to the strawman proposal was that this
is more a YANG 2.0 feature request anot not something required to
address in YANG 1.1.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Jun 2014 10:59:12 +0200

>   If many 'must' statements report the same error-app-tag and 

If a data model has a node that's used in many places with the same role and semantics, it should define a grouping for it. If this node has a 'must' statement, it is defined only once.

Otherwise, each 'must' statement corresponds to a specific context in the data model, so I guess at least the error-message should be specific as well.  
 
> server, invoking a notification,etc.

This is quite different from the above case. IMO, exceptions as they are used in programming languages should be dealt with in implementations, not in YANG. A client application receiving an error message from the server may raise an exception or handle the error by other means.

Lada

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

---

From: [email-masked]
Date: Thu, 5 Jun 2014 17:21:04 +0800

/frank

Ladislav Lhotka <[email-masked]> 写于 2014-06-05 16:59:12:

> Ladislav Lhotka <[email-masked]> 
> 2014-06-05 16:59
> 
> 收件人
> 
> [email-masked], Juergen Schoenwaelder 
> <[email-masked]>, 
> 
> 抄送
> 
> netmod <[email-masked]>, [email-masked]
> 
> 主题
> 
> Re: [netmod] strawman REJECT Y43 add exception statement
> 
> If a data model has a node that's used in many places with the same 
> role and semantics, it should define a grouping for it. If this node
> has a 'must' statement, it is defined only once.
> 
> Otherwise, each 'must' statement corresponds to a specific context 
> in the data model, so I guess at least the error-message should be 
> specific as well. 
> 

In my practice, our system(management information model) have defined many 
general 
error codes, when the constraint is invalid, many nodes would report 
general error code 
unless it's hard to describe the error using general error code.

> This is quite different from the above case. IMO, exceptions as they
> are used in programming languages should be dealt with in 
> implementations, not in YANG. A client application receiving an 
> error message from the server may raise an exception or handle the 
> error by other means.
> 
> Lada
> 

Handling exceptions is implementtation's job, I only require YANG to 
declare exceptions.

> > 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: Ladislav Lhotka <[email-masked]>
Date: Thu, 5 Jun 2014 11:50:01 +0200

On 05 Jun 2014, at 11:21, [email-masked] wrote:

> In my practice, our system(management information model) have defined many general 
> error codes, when the constraint is invalid, many nodes would report general error code 

I understand that app-tags may be general (“must constraint violated”), but it is IMO a good data modelling practice to give specific information in an error message, e.g. what does it mean in human terms that the constraint was violated.

And then, if it is only the app-tag that’s reused in many places, making a new statement for declaring it doesn’t make much sense to me. The meaning of common app-tags can be explained in a module description.

> Handling exceptions is implementtation's job, I only require YANG to declare exceptions.

YANG spec tells the implementer when an error message should be sent, and error-app-tag + error-message can be used to provide details. I don’t understand what extra information you want to communicate in an exception declaration.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 03:53:43 -0700

On Thu, Jun 5, 2014 at 2:50 AM, Ladislav Lhotka <[email-masked]> wrote:

> I understand that app-tags may be general (“must constraint violated”),
> but it is IMO a good data modelling practice to give specific information
> in an error message, e.g. what does it mean in human terms that the
> constraint was violated.
>
> And then, if it is only the app-tag that’s reused in many places, making a
> new statement for declaring it doesn’t make much sense to me. The meaning
> of common app-tags can be explained in a module description.
>
>
IMO there is no point in enhancing error-app-tag because it is handled
so badly in the NETCONF protocol. It is a flat string that has a mandatory
value for a handful of errors and utterly meaningless for everything else.

If the purpose of error-app-tag is to allow each vendor to create all the
classification systems they want, then it fails because of the handful
of mandatory error-app-tags that override the vendor.

If it is supposed to be a standard that adds reusable value then it fails
because it is 97% ad-hoc and mostly left to the vendors.

Since we have no charter to fix NETCONF there is no point in changing YANG.

Andy

> YANG spec tells the implementer when an error message should be sent, and
> error-app-tag + error-message can be used to provide details. I don’t
> understand what extra information you want to communicate in an exception
> declaration.
>
> Lada
>
> >
> > > >
> > > >
> > > > /frank
> > > >
> > 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.
> >
> >
> >
>
> --