Subject: [Supa] SUPA charter questions

From: Andy Bierman <[email-masked]>
Date: Mon, 7 Mar 2016 14:52:38 -0800

Hi,

I have read the SUPA WG charter a few times.
https://datatracker.ietf.org/wg/supa/charter/

The purpose of the YANG data models delivered
in work item (3) is not that clear to me.

3) A set of YANG data models consisting of a base policy model for
representing policy management concepts independent of the type or
structure of a policy, plus an extension for defining policy rules
according to the event-condition-action paradigm.

In the items out of scope:
Specific handling of policies (although the application document will
provide some examples). Therefore the specification of a policy engine that
maps a specific policy instance to actual configuration snippets is also
out of scope.

The charter also says:
The working group will have succeeded when the SUPA policy constructs are
re-used in future IETF specifications

Can somebody explain the purpose of the YANG modules in (3)?
What operator problems do they solve? It seems that the intent is for
SUPA to create typedefs and possibly groupings that other WGs can
use later in real YANG modules.

It seems all interactions between a controller and an NE are out of
scope and left as an implementation detail.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2016 00:23:08 +0100

> scope and left as an implementation detail.

Yep, unfortunately the SUPA charter is all about decoration but not
the cake that makes a policy engine do real stuff.

I had hoped that SUPA would allow me to express policy-driven
operations on YANG defined data models, nicely integrating with
NETCONF/RESTCONF primitives, i.e., a policy layer with well defined
primitives that operate on YANG defined data models. But somehow this
idea did not fly through the chartering process and instead SUPA is
chartered to work on another policy meta-model.

/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: joel jaeggli <[email-masked]>
Date: Mon, 7 Mar 2016 15:38:30 -0800

> chartered to work on another policy meta-model.

I'm a little disappointed with this discussion. Supa was chartered with
a explicitly simple set of work items  under the assumption that they
could be completed in a timely fashion and that the working group could
then move on.

The fact that it doesn't attempt to do everything in one go should
hopefully not be a surprise.

Appropriately minded individuals don't need permission to infill the
missing pieces for their application. the working group should not take
up such items until it's rechartered.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 7 Mar 2016 16:19:22 -0800

Hi,

IMO the charter text is not completely clear.
It reads as if the author had some phased solution in mind,
but it is not specified anywhere.  I guess we need an actual
example of the generic data models and 1 domain-specific
data model that uses them.

Andy

On Mon, Mar 7, 2016 at 3:38 PM, joel jaeggli <[email-masked]> wrote:

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2016 08:09:34 +0100

> could be completed in a timely fashion and that the working group could

For me, the idea of modeling clauses that consist of terms which again
consist of variables and operators and values all as distinct policy
objects is like letting programmers fill in the internal data
structures of a compiler directly. Nobody I know of programs at that
level of abstraction. The tools I have been using to administrate a
small zoo of Unix boxes all use domain specific languages to express
things like conditions and actions; they do not expose expression
syntax trees as the level of abstraction to an administrator.
 
> up such items until it's rechartered.

Yep. I will stay silent and check back in a couple of years. ;-)

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Mar 2016 11:40:11 -0500

With regard to using domain specific langauges for policy configuration, 
I have a number of reactions.

1) We actually allow that.  In the next revision of the information 
model, we will include for supa encoded clause a language identifier. 
THe list will be small, but extensible.  So a SUPA encoded clause can be 
used to carry / point to a domain specific langague policy expression. 
(We only noticed the absence of the language tag in an internal review 
after we sent the document to the WG.

2) In terms of modeling, a domain specific lanague is very hard to use 
interoperably.  It only works on entities that support that specific 
lanague.  We want to have a representation that is actually 
interoperable.  When you combine this with the instruction from the 
charter to focus on imperative event-condition-action policy 
expressions, we are sort of stuck with what we put in.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Mar 2016 10:27:37 -0800

> syntax trees as the level of abstraction to an administrator.

This is my reaction as well, thinking about a YANG version of the info
model.
But I don't think the charter requires that.  It seems to me the DMs in (3)
are focused on common terminology and common typedefs.
This is a useful, small step towards a solution.

When I think of simple policy examples, like the SNMP example
you suggested last year, it seems there is still a lot of
magic pushed off into implementation details.  This may be OK
or not -- we need actual solution proposals to see how the generic SUPA
data model would interact with a concrete policy like "disable SNMP
from outside this administrative domain".  For example, there is nothing
in the policy that says "use the ACL module if it is supported" or
anything else to help map the policy to an implementation.
It seems this is just hard-coded by an implementer.

What about a policy like "there must be at least
2 DNS resolvers running at all times in this administrative domain".
What does the generic YANG look like? What does the "DNS specific"
YANG look like?

This is clearly a network-wide policy that cannot be enforced or implmeneted
on a single NE.  There might be a companion NE policy that
says "every host must be configured to get DNS config from DHCP".
Verifying this NE policy gets very implementation-specific.

> Yep. I will stay silent and check back in a couple of years. ;-)

I think Joel is right that this phase should get done quickly.
It might take 2 years to agree on an info model that represents
all possible policy logic solutions.  IMO we do not need that at all
to come up with common terminology and typedefs.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2016 09:23:12 +0100

> expressions, we are sort of stuck with what we put in.

NETCONF supports XPATH filtering since its origin. The SUPAPolicyTerms
in the I-D is far from XPATH in terms of expressiveness. Very far. I
am not saying XPATH is the answer but the claim that domain specific
languages are very hard to use interoperably is surprising from a
NETCONF/YANG perspective. YANG itself is a domain specific data
modeling language...

SUPAPolicyTerms constructed out of variables, a limited set of
operators, and values really do not cut it. You can't even compare two
variables!  Parenthesis? No. Addition? No. Multiplication?  No. String
operators?  No.

And then there is a type system completely detached from YANG's type
system because it needs to be generic (and so we pick a random
selection of ~10 possibly useful types and we will worry about
figuring out how all of this maps to YANG later).

I understand that the details can be changed and improved. I do not
want to go into a discussion of details since my concern is way more
fundamental. I believe in a domain specific policy language approach
and I believe in an approach that tightly integrates with YANG (i.e.,
builds on YANG's type system and naming system). I believe it is of
key importance to make it easy for humans to read policies and to
write policies. The implementors view is of least importance.  Being
able to write down expressions on top of YANG defined data models is
where things start. I need an expression language to do that. I do not
care how this is implemented internally or how terms and clauses are
represented internally in an implementation.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Mar 2016 08:50:17 -0500

Juergen, I can not tell which of several very different requests you are 
making.

One set of interpretations relate to the expressions of constraints in 
the model.

One possible interpretation of your note is that we should include xpath 
expressions as one of the possible constraint languages in the 
Infomration Model and Data Model.

A second possible interpretation is that we should make xpath the only 
possible constraint language.

Another set relates to the policy clauses and terms we can express in 
the model.

You could be asking that we allow xpath as a language for expressing 
policy rules in the encoded clause.

You could be asking that we mandate xpath as the langauge for the 
encoded clause.

And what it looks like you are mandating is that we require that xpath 
based encoded clauses be the only way of expressing policy clauses (that 
we not allow composition in terms of variables, operators, and values.

In each of these sets of interpretations, the first request, namely 
including xpath in what can be used, seems reasonable.
Mandating xpath in this model seems quite counter-productive.

In terms of a domain specific language for expressing policy, that 
humans can work in easily, I do not consider UML, xpath, or YANG, to be 
such languages.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2016 15:52:11 +0100

Joel,

I think my message is as clear as I can express myself.

- The first paragraph responds to your claim that a domain specific
  lanague is very hard to use interoperably.

- The second and third paragraph point out examples where the I-D is
  (a) rather limited compared what NETCONF can already do using xpath
  (and see my text in paranthesis) and (b) that being generic instead
  of tight to YANG requires translations and mappings (the type system
  being an easy example since I did not find anything quickly where
  the generic model talks about instance naming).

- The last paragraph is the real essence. (i) By being generic you
  introduce a lot of additional mapping complexity. (ii) By following
  an object-oriented approach instead of a domain specific language
  approach you may make it easier for implementors but way harder for
  human policy readers and policy writers.

I used xpath as an _example_ since xpath is part of NETCONF and
YANG. xpath expressions are reasonable to read/write for humans.  What
I am looking for in my dreams is a YANG policy language that builds on
YANG (its type system, its naming, etc) and that provides me the
primitives needed to express events, conditions and actions (that
operate on YANG-defined data) in a concise syntax.

This WG may not be chartered to provide this, so I may keep dreaming
elsewhere.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Mar 2016 07:02:13 -0800

Hi,

I have also brought up XPath before as an example of an existing standard
that can be used to specify an expression.  I agree with Juergen that XPath
is far more powerful and complete than the SUPA info model logic trees.

That does not mean XPath is a policy language, but rather just a good
way to express some logic.  I would much rather fill in 1 XPath leaf
than 50 or 60 logic tree leafs.  I would rather be able to use
the YANG 1.1 XPath function library than hack new solutions to get
those same features.

I am interested in a YANG-based solution, same as Juergen.
I expect YANG to change over the years.  In fact, v. 1.1 is not
yet an RFC, so YANG is changing this year.  If it gets dumped in the future
for something better, that's fine.  We can deal with that issue if it ever
comes up.

But for now, if you have a better language for the IETF to use,
then let's see it.

Andy

On Wed, Mar 9, 2016 at 5:50 AM, Joel M. Halpern <[email-masked]> wrote:

> One set of interpretations relate to the expressions of constraints in the
> model.
>
> expressions as one of the possible constraint languages in the Infomration
> Model and Data Model.
>
> Another set relates to the policy clauses and terms we can express in the
> model.
>
> You could be asking that we mandate xpath as the langauge for the encoded
> clause.
>
> based encoded clauses be the only way of expressing policy clauses (that we
> not allow composition in terms of variables, operators, and values.
>
> In terms of a domain specific language for expressing policy, that humans
> can work in easily, I do not consider UML, xpath, or YANG, to be such
> languages.
>
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Mar 2016 10:12:30 -0500

We will include xpath  in the language lists for both constraints and 
encoded expressions in the next rev of the information model (and the 
YANG).  That makes good sense.

Yours,
Joel

On 3/9/16 10:02 AM, Andy Bierman wrote:
> for something better, that's fine.  We can deal with that issue if it
> ever comes up.
>
> On Wed, Mar 9, 2016 at 5:50 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Juergen, I can not tell which of several very different requests you
>     are making.
>
>     One set of interpretations relate to the expressions of constraints
>     in the model.
>
>     One possible interpretation of your note is that we should include
>     xpath expressions as one of the possible constraint languages in the
>     A second possible interpretation is that we should make xpath the
>     only possible constraint language.
>
>     Another set relates to the policy clauses and terms we can express
>     in the model.
>
>     And what it looks like you are mandating is that we require that
>     xpath based encoded clauses be the only way of expressing policy
>     clauses (that we not allow composition in terms of variables,
>     operators, and values.
>
>     humans can work in easily, I do not consider UML, xpath, or YANG, to
>     be such languages.
>
>     Yours,
>     Joel
>

---

From: John Strassner <[email-masked]>
Date: Thu, 10 Mar 2016 04:04:25 -0800

> NETCONF supports XPATH filtering since its origin. The
> SUPAPolicyTerms in the I-D is far from XPATH in terms
> of expressiveness. Very far.

SUPAPolicyTerm does not define a path filter. It only has a
single attribute, supaPolTermIsNegated.

Perhaps you are talking about SUPAPolicyComponentDecorator?
That class defines supaPolCompConstraintEncoding, which specifies
how to interpret the supaAPolCompConstraint attribute.

However, XPATH (whether it is 1.0 or 3.1) is NOT a constraint
language. I am confused why people think that XPATH is anything more
than a query language for selecting nodes. In contrast, this class,
and its attirbutes, are defined for expressing generic constraints. That is
why OCL, QVT, and Alloy are specified. Please read the definitions of
these languages and then explain why XPATH should be selected as a
constraint language.

That being said, if what is desired is to provide XPATH filtering, that is
a reasonable request that we can add in the next version of the I-D.
Let's just please get our terminology straight.

> variables!  Parenthesis? No. Addition? No. Multiplication?  No. String

Comparison is supported in the enumeration. Parentheses is supported
when you create the final version of the clause. Other operators are not
normative, since they may or may not be relevant for a given application.
We could certainly add text that specifies how this could be done.

The point, however, is that this is ONE of MANY options available in
creating a SUPAPolicyClause. If you don't like SUPAPolicyTerm and its
subclasses, you are not mandated to use it.

regards,
John

-- 
regards,
John