Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

[Andy Bierman <[e-mail]>]

Hi,

I think the procedures we used to follow under Marshall Rose as AD work
better than current adoption calls. First we agreed on what problem(s) to
solve.
Then we agree on solutions.  Without the first, it is hard to achieve the
second.
I would support working on a short requirements draft first, and then
revisit the
solution if that goes well.

I agree with Juergen about the complexity level for real deployments.
Decomposing logic expressions into a bunch of YANG list entries will never
work.
Just use XPath for expressions. It has variables, functions, and
expressions in compact string form.

There seems to be overlap with RFC 8632.
I would expect to see alarms reused instead of reinvented,
and ECA visibility into the notifications in each server event stream (from
RFC 8639).

The Policy Variables and RPC calls are improvements over past solutions
but still not enough to implement an ECA platform.  A real programming
language
is required, but that may not need to be standardized. Maybe just
mechanisms are needed
to bind ECA components (like PVs) to specific languages (like Python).
Then bind scripts to conditions and actions instead of using YANG objects.
All past attempts to write scripts in SMIv2 or YANG have failed.
YANG is not a programming language.


Andy


On Tue, Feb 18, 2020 at 3:17 PM Schönwälder, Jürgen <
[e-mail]> wrote:

> On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:
> > This email begins a 2 week working group adoption poll for:
> >
> > https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06
> >
> > Please voice your support or objections before the poll completes on
> > March 3rd.
>
> I am against adoption of this draft. I wonder whether Benoit will
> explain his contributions to this document; Benoit was added as a
> co-author in -06 and he used to be rather sceptical about the SUPA
> work (and this is essentially part of the SUPA work resubmitted to the
> NETMOD WG). Despite this, the YANG definitions are clearly not up to
> the level one would expect for WG adoption. Many descriptions are
> just repetition of leaf names and there are obvious errors such as
>
>           leaf-list day-of-month {
>             type uint8 {
>               range "0..59";
>             }
>             description
>               "A set of days of the month at which this
>                scheduling timing will trigger.";
>           }
>
> Despite the strange range, it is unclear how a number will in the
> range will identify a set. Note, this is an example, there are lots of
> them in the document. The examples provides are not convincing and
> technically wrong (how can <interval>10m</interval> match
>
>           leaf interval {
>             type uint32 {
>               range "1..max";
>             }
>             units "seconds";
>             mandatory true;
>             description
>               "The number of seconds between two triggers
>                generated by this periodic timing object.";
>           }
>
> and I have serious doubts that the design is anywhere close to be
> practically usable. There need to be mechanisms to bind 'variables'
> while matching conditions that and be reused in action definitions, it
> is not scalable to have constants such as interface names in the
> examples hard-coded in policy rules - this would lead to a huge number
> of rules if you want to apply policy rules to all interfaces.
>
> There is also a lack of extensibility, which is important for a core
> policy language, and definitions like:
>
>   identity function-type {
>     description
>       "Possible values are:
>        plus, minus, mult, divide, remain.";
>   }
>
> without ever defining these operators feels strange. I also not
> convinced that the resulting expressions are expressive enough for
> real-world use.
>
> This document is in a state that requires way too much effort to fix
> in a WG process. I also doubt that expressing policies in such a
> low-level format is usable in practice. Policy languages for network
> management have a long history and this proposal seems to ignore the
> lessons learned in the past.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>