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

[Schönwälder, Jürgen <[e-mail]>]

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/>