Re: [Supa] question on the SUPA data model.

["Joel M. Halpern" <[e-mail]>]

I am not sure what youa re asking.
In building an actual policy system, there need to be subclasses of 
"Action".  For example, One might have a subclass which is "invoke YANG 
RPC".  It has attributes for the YANG Verb, the XPATh target and the 
parameters.
I presume one could have a subclass for "invoke OVSDB configuration".

One might want more specific subclasses to enable better modeling and 
analysis.  So while one might be using YANG for sending policies from a 
higher level system to a lower level one, one could also have a more 
specific class for "configure child policy".  Not sure if it is needed, 
but it is certainly possible.

Yours,
Joel

On 3/16/17 8:36 AM, youlizhao wrote:
> Hi John,
>
>
>
> Thanks a lot for your detailed guidance.
>
> One remaining question is that, if I want to define an Action, do we
> follow the similar approach? It seems that it is difficult to define
> Actions based on a uniform format. Does it mean that we need the Augment
> clause as defined in the YANG language?
>
>
>
> Thanks.
>
>
>
>
>
> Regards,
>
> Leo
>
> ----------------------------------------------------------------------------------------------//
>
> /Lizhao (Leo) You, PhD/
>
> /Senior Research Engineer/
>
> /Huawei Technologies Co.,Ltd/
>
> /[e-mail]/ <mailto:[e-mail]>//
>
> /Tel: [phone]/
>
> /www.linkedin.com/in/lizhao-you/
>
> ----------------------------------------------------------------------------------------------//
>
>
>
> *From:*John Strassner [mailto:[e-mail]]
> *Sent:* 2017年3月3日3:57
> *To:* Liushucheng (Will Liu) <[e-mail]>; John Strassner
> <[e-mail]>
> *Cc:* [e-mail]; supa
> <[e-mail]>; youlizhao <[e-mail]>
> *Subject:* Re: [Supa] question on the SUPA data model.
>
>
>
> Hi Will,
>
>
>
> The answer to your question depends on how you plan to use these five
> attributes. My **guess** is that you want to use them as variables in
> condition or action clauses. If this is correct, then there are several
> ways to model your five attributes; the two simplest are
>
>    1) as SUPAEncodedClauses, where the expression involving the
>        attribute is encoded into an attribute value
>    2) as SUPAPolicyTerms (e.g., using a combination of
>        SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue)
>
>
> #1 is the simplest approach; #2 is useful **if** the terms in the
> SUPAPolicyClause are common objects whose attributes are manipulated.
> In effect, it makes each of the {variable, operator, value} terms in the
> canonical form of a SUPAPolicyClause reusable.
>
> There is another important difference between the two approaches. A
> SUPAEncodedClause represents a **complete** SUPAPolicyClause. In
> contrast, SUPAPolicyTerms are used to define SUPAPolicyVariables,
> SUPAPolicyOperators, and SUPAPolicyValues as **reusable objects**;
> this means that you "attach", or "wrap", them to a subclass of
> SUPAPolicyClause. Put another way, the first method allows you to build
> a complete SUPAPolicyClause in one object, while the second method
> allows you to define a SUPAPolicyClause in terms of reusable objects.
> The second method is preferable when you have to dynamically substitute
> elements of a SUPAPolicyClause (e.g., variables).
>
> The following shows how to build a simple example using both approaches.
>
> Let's assume you want to be able to write:
>
>    IF source_port == 67
>
>
> Method #1: Using SUPAEncodedClause
>
> Defining a SUPAEncodedClause is straightforward, as you are **not**
> (typically) using any of the SUPAPolicyComponentDecorator subclasses,
> since the SUPAEncodedClause is, itself, a complete SUPAPolicyClause. You
> have a single object to represent the entire SUPAPolicyClause, which is
> an instance of the SUPAEncodedClause class. Its attributes are:
>
>    supaEncodedClauseContent:      "IF source_port == 67"
>    supaEncodedClauseEncoding:    9         // string_instance_id
>    supaEncodedClauseLanguage:   2         // text
>    supaEncodedClauseResponse:  TRUE  // this is meant to be set at
>                                                                    //
> runtime after evaluation of the
>
>                                                                    //
> clause by the PolicyEngine
>
> Now, if you want to say:
>
>    IF source_port = 67 OR source_port = 68
>
> Then simply modify the text of supaEncodedClauseContent.
>
>
> Method #2: Using SUPAPolicyTerms
>
> In this method, the first task is to build three objects:
>
>    SUPAPolicyVariable, with its attribute supaPolVarName set to
>       "source_port" (a string)
>    SUPAPolicyOperator, with its attribute supaPolOpType set to 6 (which
>       signifies "equal to")
>    SUPAPolicyValue, with its attributes supaPolValContent and
>      supaPolValEncoding set to 67 and 3 (3 means "integer"), respectively
>
> These all subclass from SUPAPolicyComponentDecorator, which means that
> they can decorate a SUPAPolicyClause. Now, the second task is to choose
> a subclass of SUPAPolicyClause to attach these three objects to. Let's
> assume that you choose SUPABooleanClauseAtomic. The attribute values of
> SUPABoolean clause are:
>
>    supaBoolClauseIsNegated is set to FALSE
>    supaBoolClauseBindValue is set to 1
>    supaBoolClauseIsCNF is set to TRUE
>
> Note that in -02 of the IM document, the latter two attributes were
> defined only in the SUPABooleanClauseComposite class. This has been
> changed in the upcoming -03 IM document (to be published soon), and all
> three of the above attributes are moved to SUPABooleanClause, so that
> they are available to both of its subclasses.
>
> Now, if you want to say:
>
>    IF source_port = 67 OR source_port = 68
>
> Then simply repeat the above procedure to create another set of
> SUPAPolicyVariable, SUPAPolicyOperator, and SUPAPolicyValue objects,
> form another SUPABooleanClauseAtomic object (whose
> supaBoolClauseBindValue is now set to 2, but whose other attributes
>
> remain the same*), and now create a new
>
> SUPABooleanClauseComposite object to bind them together.
>
>
>
> * Note that A OR B is in conjunctive normal form, because it can be
>
> seen as the conjunction of the two single-literal clauses. Note also that
>
> both A OR B and A AND B can also be seen as being in DNF.
>
>
>
>
>
> best regards,
>
> John and Joel
>
>
>
> On Thu, Feb 16, 2017 at 12:20 AM, Liushucheng (Will)
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi all,
>
>
>
>     I received a question to SUPA data model from a developer. I’m
>     forwarding it here so that the discussion here will help other
>     developer to better understand how to use supa data model.
>
>
>
>     --start—
>
>     Dear SUPA YANG model authors,
>
>
>
>     Thanks for drafting the SUPA Generic Policy YANG data model
>     (draft-ietf-supa-generic-policy-data-model-02), and it explains the
>     concept well. However, I met some difficulties when applying the
>     data model to real systems. In particular, I tried to define an ECA
>     YANG model, and used the ECA YANG model to develop a real working
>     system.
>
>
>
>     In my system, there are some concrete elements such as <source_ip,
>     source_port>, <dest_ip, dest_port>, port_bandwidth, and ECA policies
>     are defined on these elements. I wondered how to deal with these
>     elements/policies in the Generic YANG model
>     (draft-ietf-supa-generic-policy-data-model-02)? (e.g., enrich some
>     container?)
>
>
>
>     I would greatly appreciate it if you kindly give me some advice.
>     Many thanks!
>
>
>
>     Regards,
>
>     Leo
>
>     --end--
>
>
>
>     Regards,
>
>     Will (Shucheng LIU)
>
>
>
>
>     _______________________________________________
>     Supa mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/supa
>
>
>
>
> --
>
> regards,
>
> John
>
>
>
> _______________________________________________
> Supa mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/supa
>