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

[John Strassner <[e-mail]>]

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]
> 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]
> https://www.ietf.org/mailman/listinfo/supa
>
>


-- 
regards,
John