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

[John Strassner <[e-mail]>]

Hi Frank,

sorry for the delay in replying.

> Rule prioritization example

[Frank]:  Take this example, I am a little worried about the complexity
brought by the nesting and recursion operation. They are powerful but also
complicated. I think we should be careful in designing the information
model to prevent it to be too complex.

<jcs>
That was the point. :-) In particular, PCIM and PCIMe (and CIM) collapse
under the weight of the numerous relationships that must be instantiated.
Looking ahead to generating YANG, I see no point in building a model that
requires countless leaf nodes just to express simple Boolean clauses.

SUPA is designed to give the developer choices in how such clauses are
implemented (e.g., the entire clause as one object, the entire clause as a
URI (for example) to a script, each and every little variable, operator,
and value as an object (to facilitate a machine building this dynamically),
or others in between these scopes. Of course, I2NSF doesn't have to use
SUPA, but hopefully, SUPA can answer questions about what the best security
policy rule structure would be.
</jcs>

> Context-aware policy rules

[Frank]: This context-aware policy rules make sense for I2NSF in my
opinion. Are you going to introduce it into I2NSF?


<jcs>
Yes. :-) But this is why we need to be very careful about terminology
(i.e., context). I would like to work with you and your co-authors on your
Capability Interface information model I-D as one place to introduce this...
</jcs>

regards,
John

On Thu, Dec 10, 2015 at 10:52 PM, Xialiang (Frank) <
[e-mail]> wrote:

> Hi John,
>
> Firstly, thanks for raising this valuable discussion about I2NSF policy
> model. It’s really useful to our interface information model drafts.
>
> Please see my comments inline:
>
>
>
> B.R.
>
> Frank
>
> *发件人:* I2nsf [mailto:[e-mail]] *代表 *John Strassner
> *发送时间:* 2015年12月11日 4:43
> *收件人:* Linda Dunbar; John Strassner
> *抄送:* [e-mail]; Natale, Bob
> *主题:* Re: [I2nsf] Service Layer Policies - Post 1: Background Information
> on PCIM
>
>
>
> Hi Linda,
>
>
>
> IMHO, a priority attribute should not be overly used. PCIM's
> implementation fails (see Post 1), and PCIMe's has other problems (defined
> in Post 2, hopefully out tonight). For example, how do you ensure that the
> priorities of all instances of all rules are always updated? There is no
> mechanism in either PCIM or PCIMe that guarantees that priorities are
> deterministically determined. Remember, you can have priorities on policy
> rules, and priorities on policy groups. So, if you had:
>
>
>
>    Group1 (priority 5)
>
>       Rule A (priority 10)
>       Rule B (priority 1)
>
>       Rule C (priority 50)
>
>    Rule 2 (priority 10)
>
>    Group 3 (priority 3)
>
>       Rule x, priority y
>
>
>
> Rule 2 will execute first, even though Group1.RuleC.priority == 50
>
> Likewise, it doesn't matter how many rules are in Group 3, or what their
> priorities are, they will all execute after Rule2, followed by the Rules in
> Group1 (C, A, B).
>
> This gets harder as you start nesting groups within groups and rules
> within rules.
>
> [Frank]:  Take this example, I am a little worried about the complexity
> brought by the nesting and recursion operation. They are powerful but also
> complicated. I think we should be careful in designing the information
> model to prevent it to be too complex.
>
>
>
> PCIMe has a policyDecisionStrategy attribute, which is used to define
> whether the container (PolicyGroup or PolicyRule) of the PolicyRules uses
> first-match or all-match. This obfuscates the value of the priority
> attribute.
>
>
>
> As Bob rightly pointed out, execution context is everything. In FOCALE, I
> defined context-aware policy rules. Context was used to select a working
> set of policies; this working set collectively constituted the intelligence
> that the manager implemented. Tie that into feedback from what was being
> managed, and as the overall context changes, the working set of policies
> change. Kinda cool. But NOT maintainable using just priority.
>
> [Frank]: This context-aware policy rules make sense for I2NSF in my
> opinion. Are you going to introduce it into I2NSF?
>
>
>
> regards,
>
> John
>
>
>
> On Thu, Dec 10, 2015 at 9:32 AM, Linda Dunbar <[e-mail]>
> wrote:
>
> Bob,
>
>
>
> Thank you very much for listing down multiple scenarios below.
>
> With what you described, the I2NSF rule-set may need a priority so that
> the NSF can enforce them accordingly.
>
> In our current product implementation, the router’s longest match
> principle has been used, i.e. rules for individual hosts override the rules
> for the subnet to which that hosts belong.
>
> But there could be more complicated conflict that what is listed below.
> Having a priority can be more precise.
>
>
>
>
>
> Linda
>
>
>
> *From:* Natale, Bob [mailto:[e-mail]]
> *Sent:* Thursday, December 10, 2015 12:47 AM
> *To:* Linda Dunbar; John Strassner
> *Cc:* [e-mail]
> *Subject:* RE: [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> 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] <[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
>



-- 
regards,
John