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

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

That is close.  I would not describe SUPA as a meta-model, but rather as 
the upper levels of abstraction which define the structure within which 
the more detailed elements will fit.

Yours,
Joel

On 3/21/17 10:41 PM, youlizhao wrote:
> Hi John and Joel,
>
>
>
> I am sorry for being unclear. I hoped to figure out what the Action YANG
> model looks like, and how to implement it.
>
>
>
> John’s email made me realize there were some discussions (e.g., the SNMP
> blocking example). I will digest the discussions to see if I can design
> a similar model for my system.
>
>
>
> I thought ECA YANG model should similar to some service models such as
> L2SM/L3SM which have well-defined properties to follow.  It seems that
> different systems may have different definitions of
> Event/Condition/Action, and the meta-YANG model is what SUPA wants to
> define. Am I correct?
>
>
>
> Thanks.
>
>
>
> Regards,
>
> Leo
>
>
>
> *From:*John Strassner [mailto:[e-mail]]
> *Sent:* 2017年3月17日4:39
> *To:* Joel M. Halpern <[e-mail]>; John Strassner
> <[e-mail]>
> *Cc:* youlizhao <[e-mail]>; Liushucheng (Will Liu)
> <[e-mail]>; supa <[e-mail]>
> *Subject:* Re: [Supa] question on the SUPA data model.
>
>
>
> Hi Leo,
>
>
>
> I agree with Joel's comments on Actions. It depends on whether
>
> you are talking **model** or **implementation**.
>
>
>
> Assuming you are talking model, you could do this in a number
>
> of ways:
>
>
>
>    1) follow a similar course to that outlined in the SNMP blocking
>
>        example, part 1 (section X.1.3), and use a generic
>
>        SUPAPolicyAction. This is good for generic solutions, but
>
>        is NOT YANG. So, this object would be passed to software
>        that knew how to translate it to YANG and Netconf.
>
>    2) follow a similar course to that outlined in the SNMP blocking
>
>        example, part 2 (section X.1.4), by creating a subclass of
>
>        SUPAPolicyAction, called (for example)
>
>        SUPAPolicyActionNetConf, and populate its three
>
>        exemplar attributes in a manner similar to that shown
>
>
>
> If you are talking what the YANG would look like, or something
>
> else, please let us know, and we're happy to help.
>
>
>
> best regards,
>
> John
>
>
>
> On Thu, Mar 16, 2017 at 7:44 AM, Joel M. Halpern <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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]/ <http://[e-mail]/>
>         <mailto:[e-mail] <mailto:[e-mail]>>//
>
>         /Tel: [phone] <tel:%2B86-1304-942-7487>/
>
>         /www.linkedin.com/in/lizhao-you/
>         <http://www.linkedin.com/in/lizhao-you/>
>
>         ----------------------------------------------------------------------------------------------//
>
>
>
>         *From:*John Strassner [mailto:[e-mail]
>         <mailto:[e-mail]>]
>         *Sent:* 2017年3月3日3:57
>         *To:* Liushucheng (Will Liu) <[e-mail]
>         <mailto:[e-mail]>>; John Strassner
>         <[e-mail] <mailto:[e-mail]>>
>         *Cc:* [e-mail]
>         <mailto:[e-mail]>; supa
>         <[e-mail] <mailto:[e-mail]>>; youlizhao
>         <[e-mail] <mailto:[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]>
>         <mailto:[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]> <mailto:[e-mail]
>         <mailto:[e-mail]>>
>             https://www.ietf.org/mailman/listinfo/supa
>
>
>
>
>         --
>
>         regards,
>
>         John
>
>
>
>         _______________________________________________
>         Supa mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/supa
>
>
>
>
> --
>
> regards,
>
> John
>