Re: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

[John Strassner <[e-mail]>]

Good point, Bob!

Note that PCIM does not even have a scalable priority mechanism to
disambiguate this conflict. PCIMe is better, but still flawed (sorry, I'm
trying to finish post 2).

best regards,
John

On Wed, Dec 9, 2015 at 10:46 PM, Natale, Bob <[e-mail]> wrote:

> Hi Linda,
>
>
>
> Input here from a lurker … calibrate accordingly!
>
>
>
> You asked:
> “[Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>
> 1.        Virtual Network X can’t access “YouTube”,
>
> 2.       10.1.1.1 can access “YouTube” (where 10.1.1.1 is a host within
> the Virtual Network X).
>
> Do you call the 2 rules above conflict?”
>
> The answer is “it depends” … depends on a broader policy execution context
> … a concept that PCIM itself does not directly support. For example, that
> broader context could stipulate (via policy) that #1 is the default but
> explicit exception specifications like #2 can override the default …
> alternatively, that broader context could stipulate that #1 is absolute and
> any attempt to specify (preferably) or execute #2 would be denied … those
> are only two examples, there are multiple potentially valid variations. How
> much of that context a group wants to standardize is an important decision
> for the group to understand and make … PCIM itself will not take you very
> far, however.
>
> Avanti,
>
> BobN
>
>
>
> *From:* I2nsf [mailto:[e-mail]] *On Behalf Of *Linda Dunbar
> *Sent:* Tuesday, December 08, 2015 4:11 PM
> *To:* John Strassner <[e-mail]>; [e-mail]
> *Subject:* Re: [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> John,
>
>
>
> Thank you very much for the in-depth analysis of PCIM and its suitability
> as something that I2NSF should be based on. What you write is very
> valuable. I think the analysis should be added to the I2NSF gap analysis,
> (or be a standalone Policy Analysis ID).
>
>
>
> I have some questions inserted below:
>
>
>
> *From:* I2nsf [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *John Strassner
> *Sent:* Sunday, December 06, 2015 7:01 PM
> *To:* [e-mail]
> *Subject:* [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> <Snipped>
>
>
>
> 2.  Brief description of PCIM
>
>
>
> The PCIM Class Hierarchy is very simple, as this is a CA
> (condition-action) model. Events are NOT represented. PCIM defines a
> PolicyRule, a PolicyGroup (group of PolicyRules), PolicyCondition, and
> PolicyAction. These are all siblings; their common superclass is called
> Policy, as shown below:
>
>
>
> ManagedElement (abstract)
>   |
>   +---Policy (abstract)
>   |     |
>   |     +---PolicyGroup
>   |     |
>   |     +---PolicyRule
>   |     |
>   |     +---PolicyCondition (abstract)
>   |     |      |
>   |     |      +---PolicyTimePeriodCondition
>   |     |      |
>   |     |      +---VendorPolicyCondition
>   |     |
>   |     +---PolicyAction (abstract)
>   |            |
>   |            +---VendorPolicyAction
>
>
>
> Note: PCIM does have a simple notion of Roles, but implements them as
> attributes, instead of objects. This is not scalable, and does not fully
> realize the power of using roles. This will be discussed more in Post 3.
>
>
>
> Note: It is possible to define limited constraints in PCIM as conditions.
> For example, the VendorPolicyCondition class has two attributes, Constraint
> and ConstraintEncoding, that do this. This will be discussed more in Post 4.
>
>
>
> Note: Context is NOT defined in the PCIM.
>
>
>
> [Linda]  Do you agree that “Condition of the PCIM” == “I2NSF subject” &
> “the Contextual states (or the I2NSF object)”?
>
>
>
>
>
> 3.  Summary: main drawbacks of using PCIM
>
>
>
> Note that the current CIM Policy Model (2.44.1) is significantly different
> than either PCIM or PCIMe. PCIM is based on CIM 2.4; PCIMe is based on CIM
> 2.5. PCIMe is NOT backwards compatible with PCIM in all areas.
>
>
>
> Critical Problems:
>
>    - There is no unique ID that can be used to distinguish different
>    instances of the same PolicyRule, PolicyGroup, PolicyCondition,
>    or PolicyAction.
>
> [Linda] Can we simply create an ID (string or numeric) for instances of
> the same PolicyRule? Or it is more complicated?
>
>    - Relationships are implemented by defining an abstract class
>    with keys, and then overriding the keys in the subclasses of the
>    relationship. This is broken. Would you override keys in an RDBMS?
>
> [Linda] Is the “Key” to differentiating different “PolicyRule”?   Can you
> give an example of “subclasses of the relationship”?
>
> What events can cause “overriding the keys in the subclasses of the
> relationship”?
>
>    - Most of the classes that are used to implement the relationships
>    do NOT have attributes, so it is impossible to restrict which
>    classes are related to which other classes (e.g., by context).
>    Put another way, the same relationship must always be used
>    between two types, even if the semantics varies. (The two
>    exceptions are PolicyConditionInPolicyRule and
>    PolicyActionInPolicyRule).
>
> [Linda] Does “classes” == “PolicyRule”?
>
>    - The "ignore this unless you need this" philosophy does not
>    work. How do you know if other implementations that you are
>    supposed to interoperate with are using them?
>
> [Linda] Is “Ignore this unless you need this” an new type of “PolicyRule”?
>
>    - There is no concept of error or exception handling
>    - There is no concept of the subject or the target of a policy
>
> [Linda] Does your “subject” have the same meaning as the “I2NSF subject”
> which means bits&bytes extracted from packets?
>
>    - Adding a new type of policy (e.g., declarative or functional)
>    will cause a major rewrite of the entire model
>
>
>
> [Linda] Can we say that  I2NSF policies have one type
> “Subject-ContextualStates- action- function? So in I2NSF environment, there
> is only the notion of adding a new “PolicyRule”, but no adding a new policy
> type. Is this correct statement?
>
>    - There is no approach to detecting and solving policy conflicts;
>    this is due to the simplistic notion of just using a PDP and a
>    PEP for applying policies.
>
>
>
> [Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>
> 1.        Virtual Network X can’t access “YouTube”,
>
> 2.       10.1.1.1 can access “YouTube” (where 10.1.1.1 is a host within
> the Virtual Network X).
>
> Do you call the 2 rules above conflict?
>
>
>
>
>
> 4. Recommendations
>
>
>
> Given the large amount of problems, I recommend that we not consider PCIM
> further.
>
> [Linda] should I2NSF reference PCIM?
>
>
>
> Thank you very much. Linda
>
>
>
> 5. Origin of PCIM/PCIMe
>
>
>
> This is a **theory** section; please skip unless you want to understand
> the model in more detail.
>
>
>
> The PCIM is based on the DMTF CIM, which is actually a **data model**
> (despite its name) because it uses relational technologies (e.g., keys and
> weak references) to create its model. PCIM is based on an early version of
> the CIM (2.4); the current version of the CIM is 2.44.1 as of this writing.
> Since this is tied to the CIM, this means that:
>
>
>
>    1) Policy is subclassed from a more generic class (ManagedElement)
>
>    2) ALL relationships (associations, aggregations, and compositions)
>
>        are realized as **classes**
>
>    3) As a result of 2), relationships are subclassed
>
>    4) Both attributes and associations are **inherited**
>
>    5) The same design approach (as much as possible) was used in
>
>         PCIM/PCIMe as was in CIM. Specifically, it was thought better
>
>         to define a generic, but optional, relationship instead of not
>
>         defining the relationship.
>
>    6) The CIM does NOT have a single rooted hierarchy; this makes
>
>         code generation more complex
>
>    7) The CIM uses a proprietary language and is not strictly UML
>
>         compliant, even though it looks like UML (unfortunately, this
>
>         language is also called MOF)
>
>
>
> Depending on the complexity of the implementation, the above have been
> shown to produce problems in large environments. For example, the spirit of
> "let's define an attribute or association in case it is useful, and make it
> optional so you don't have to worry about it" not only violates some
> well-known software architectural guidelines (e.g., Single Responsibility
> Principle and the Liskov Substitution Principle), but it makes things
> difficult to interoperate with (since you never really know if an attribute
> or relationship should be instantiated or not).
>
>
>
>
>
> regards,
>
> John
>



-- 
regards,
John