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

[John Strassner <[e-mail]>]

Hi Linda,

thank you for your kind words. My replies are inline:

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).


<jcs>
If desired, I could summarize the key points for the gap analysis. I would
be willing to do a Policy Analysis I-D, but I think that this probably
belongs in SUPA. However, feedback from I2NSF is invaluable for such a
document.
</jcs>


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)”?


<jcs>

PCIM/PCIMe conditions are clearly similar to what is now called "I2NSF
Subject". However, the contextual state is trickier. Part of the problem is
how we want to define Context. I'll save the bulk for Post 4 (as outlined
in my Post 0 note). However, looking at page 6 of
draft-merged-i2nsf-framework-04:

"Object-Match values, based on context (e.g., state, direction of the
traffic, time, geo-location, etc.)", in which case:

   - state:  likely NOT part of the condition; rather, it applies to the
entire PolicyRule as a whole

   - traffic direction:  part of the condition

   - time:  part of the condition

   - geo-location:  part of the condition

</jcs>



...


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?


<jcs>

SUPA and DEN-ng use two attributes to do this:


   - a string that contains the content of the identifier

   - a string that is an enum, which defines how to interpret the content


This allows different IDs to be mixed (e.g., URIs, GUIDs, keys, FQDNs, etc.)


That being said, it is certainly easier to pick one and go with it, but
since I2NSF SHOULD interoperate with other models easily, I would recommend
a scheme similar to the one I used (or the above, of course).

</jcs>



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”?


<jcs>
No, the key (as in primary and foreign keys, just to be clear) is used as
part of how CIM data models are built. I believe that this strategy is
fundamentally incorrect (as in, would you override keys in an RDBMS). It
also violates a host of object-oriented principles (see Post 2b).


Remember, PCIM and PCIMe do NOT define events. This is a design
(compile-time) definition of how you build CIM classes.
</jcs>



- 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”?


<jcs>

No, "classes" == {association | aggregation | composition}.


This is another artifact of CIM. They implement ALL relationships as
classes. In UML, there is a difference between these three relationships
and realizing them as a class; the CIM approach eliminates this distinction.

</jcs>




   - 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”?


<jcs>

No, sorry, this is one of the key points underlying the design philosophy
of CIM, and carried into PCIM and PCIMe. Basically, it means that it is OK
to define model elements on another model element if they are optional.
Examples:


   - defining an optional attribute, method, or relationship on a class
   - defining an optional constraint


This violates all of the 4 design principles in Post 2b (references section)

</jcs>



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?


<jcs>

No. A PolicySubject is the author of a policy. One could also differentiate
between author, owner, and executor, but that is more complex. It is vital
for deontic logic (i.e., the logic of obligations and permissions, as in
MUST, MUST NOT, SHOULD, MAY, etc.). This is one of my concerns with the
Sbbject-Object-Action-Function model - one cannot build authorization
policies that can be logically proven to be correct or not without a
PolicySubject.

</jcs>



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?


<jcs>

No. The meaning of what I wrote above is much broader. If you think of ECA
policies as imperative in nature, then the analogy is that PCIM/PCIMe are
hard-wired to imperative policies. The schema cannot be used for other
forms (declarative, functional, etc.) of policies.


Put another way, ECA (or CA, which is all that the PCIM/PCIMe can do) is
imperative - it specifies that, given this particular state, the ONLY state
that you are allowed to transition to is this other state. Rationality MUST
be compiled into the policy. In contrast, for declarative logic, given a
particular state, there are a SET of states that either satisfy the goal,
or take you closer to the goal. Hence, rationality is GENERATED by a logic
planner/optimizer.

</jcs>



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?

<jcs>

Bob already answered this in
http://www.ietf.org/mail-archive/web/i2nsf/current/msg00729.html

+1 to his answer (or see my reply)

</jcs>



Given the large amount of problems, I recommend that we not consider PCIM
further.

[Linda] should I2NSF reference PCIM?


<jcs>

I don't see any harm in **referencing** PCIM or PCIMe; I just don't want to
**use** either to construct our policies.

</jcs>



best regards,

John



On Tue, Dec 8, 2015 at 1:10 PM, Linda Dunbar <[e-mail]>
wrote:

> 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]] *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