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

From: John Strassner <[email-masked]>
Date: Sun, 6 Dec 2015 17:01:04 -0800

The I2NSF framework draft mentions PCIM (RFC3060) and PCIMe (RFC3460) as
possible candidates for guiding the policy structure that can be mapped to
the Capability Layer's "Subject-Object-Action-Function" paradigm. This note
provides a brief analysis of the suitability of PCIM and PCIMe for this
task. I have tried to avoid model-theoretic essays as much as possible.

Sorry for the length of this note, but RFC3060 is a 100-page document, and
this is a complex subject. Therefore, I have tried to keep this as brief as
possible. If you need more explanation on the conclusions in section 3,
please do not hesitate to ask!

1.  Terminology

   An information model is a representation of concepts of interest
   to an environment in a form that is independent of data repository,
   data definition language, query language, implementation language,
   and protocol.

   A data model is a representation of concepts of interest to an
   environment in a form that is dependent on data repository, data
   definition language, query language, implementation language, and
   protocol (typically, but not necessarily, all three).

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.

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.
   - 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?
   - 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).
   - 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?
   - There is no concept of error or exception handling
   - There is no concept of the subject or the target of a policy
   - Adding a new type of policy (e.g., declarative or functional)
   will cause a major rewrite of the entire model
   - 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.

Major Problems:

   - The notion of "rule-specific" or "reusable" does not make sense.
   ANY object should be reusable. Worse, this affects the naming
   of the CIM classes.
   - PolicyGroup does not prevent defining loops of PolicyRules.
   - PolicyGroup uses a recursive aggregation for nesting; this
   causes unexpected behavior the further the nesting goes
   - The PolicyGroup recursive aggregation also does not support
   the aggregation of PolicyRules AND PolicyGroups; it is an
   either-or aggregation
   - Different classes are required to associate each condition with
   a PolicyRule
   - Different classes are required to associate each action with
   a PolicyRule
   - PolicyRule has a priority attribute; this can NOT be used to
   resolve priorities across nested PolicyRules and PolicyGroups
   - The aggregation PolicyActionInPolicyRule has an actionOrder
   attribute, which has 2 problems:
      1) this can NOT be used to define the order of actions
          across nested PolicyRules and PolicyGroups
      2) this is a very fragile mechanism for establishing the
          order of actions within a PolicyRule (e.g., no mechanisms
          are defined for verifying the order of actions is correct)
   - PolicyRule defines roles as a set of strings; this is NOT
   optimal, as will be explained in my next post (#3)
   - The associations PolicyInSystem, PolicyGroupInSystem,
   and PolicyRuleInSystem are superfluous; modern software
   techniques like introspection or reflection do the same
   things in more powerful ways.

Minor Problems

   - Policy inherits at least 5 recursive relationships that are not
   useful for Policy-based Management.
   - Policy inherits at least 3 attributes that are not useful for
   Policy-based Management
   - PolicyGroup has no useful attributes defined
   - PolicyCondition is an abstract class with no attributes defined
   - PolicyTimePeriodCondition lacks full time capabilities (e.g., local
   time, lunar calendar, etc.)
   - PolicyAction is an abstract class with no attributes defined

4. Recommendations

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

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

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 8 Dec 2015 21:10:57 +0000

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:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, December 06, 2015 7:01 PM
To: [email-masked]
Subject: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

<Snipped>

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:

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.

[Linda]  Do you agree that “Condition of the PCIM” == “I2NSF subject” & “the Contextual states (or the I2NSF object)”?

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:

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

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 10 Dec 2015 06:46:39 +0000

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:

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:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, December 08, 2015 4:11 PM
To: John Strassner <[email-masked]>; [email-masked]
Subject: Re: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

John,

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Sunday, December 06, 2015 7:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

<Snipped>

Critical Problems:

4. Recommendations

5. Origin of PCIM/PCIMe

regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 10 Dec 2015 17:32:19 +0000

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:[email-masked]]
Sent: Thursday, December 10, 2015 12:47 AM
To: Linda Dunbar; John Strassner
Cc: [email-masked]
Subject: RE: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

Hi Linda,

You asked:

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, December 08, 2015 4:11 PM
To: John Strassner <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

John,

<Snipped>

Critical Problems:

4. Recommendations

5. Origin of PCIM/PCIMe

regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 10 Dec 2015 12:14:46 -0800

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 <[email-masked]> wrote:

> “[Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>
> 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:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Tuesday, December 08, 2015 4:11 PM
> *To:* John Strassner <[email-masked]>; [email-masked]
> *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).
>
>
>
> *From:* I2nsf [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *John Strassner
> *Sent:* Sunday, December 06, 2015 7:01 PM
> *To:* [email-masked]
> *Subject:* [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> <Snipped>
>
>
>
> 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:
>
>
>
> [Linda]  Do you agree that “Condition of the PCIM” == “I2NSF subject” &
> “the Contextual states (or the I2NSF object)”?
>
>
>
>
>
> [Linda] Can we simply create an ID (string or numeric) for instances of
> the same PolicyRule? Or it is more complicated?
>
> [Linda] Is the “Key” to differentiating different “PolicyRule”?   Can you
> give an example of “subclasses of the relationship”?
>
> [Linda] Does your “subject” have the same meaning as the “I2NSF subject”
> which means bits&bytes extracted from packets?
>
> [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?
>
> [Linda] in I2NSF, there could be a lot of conflicts, for example, there
> could be two rules entered at different time:
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 10 Dec 2015 12:43:25 -0800

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.

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.

regards,
John

On Thu, Dec 10, 2015 at 9:32 AM, Linda Dunbar <[email-masked]>
wrote:

> 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.
>
> *From:* Natale, Bob [mailto:[email-masked]]
> *Sent:* Thursday, December 10, 2015 12:47 AM
> *To:* Linda Dunbar; John Strassner
> *Cc:* [email-masked]
> *Subject:* RE: [I2nsf] Service Layer Policies - Post 1: Background
> Information on PCIM
>
>
>
> Hi Linda,
>
>
>
> Behalf Of *Linda Dunbar

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Fri, 11 Dec 2015 06:52:42 +0000

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:[email-masked]] 代表 John Strassner
发送时间: 2015年12月11日 4:43
收件人: Linda Dunbar; John Strassner
抄送: [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> wrote:
Bob,

Linda

From: Natale, Bob [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 10, 2015 12:47 AM
To: Linda Dunbar; John Strassner
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

Hi Linda,

You asked:

John,

<Snipped>

Critical Problems:

4. Recommendations

5. Origin of PCIM/PCIMe

regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Fri, 11 Dec 2015 15:32:20 -0800

Hi Linda,

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

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

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

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>

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

<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

<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

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

2.      10.1.1.1 can access “YouTube” (where 10.1.1.1 is a host within the
Virtual Network X).

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

<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 <[email-masked]>
wrote:

> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 14 Dec 2015 02:45:14 +0000

Hi John,
Since current design principle for the policy model of capability interface is to abstract from most common existing NSF security policy implementations and consolidate them into a general and extensive model, I think imperative logic is more suitable for this goal.

I am very interested in whether “event” can be used in I2NSF capability interface. Do you have some suggestions?

Are the “subject” and “target” two different classes in PCIMe? Do you suggest to include them in I2NSF policy model of capability interface for the goal of authorizing the policy?

B.R.
Frank

发送时间: 2015年12月12日 7:32
收件人: Linda Dunbar
抄送: [email-masked]

Hi Linda,

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

<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:

<jcs>

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>

<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

<jcs>

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>

<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:

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

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

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>

<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 <[email-masked]<mailto:[email-masked]>> wrote:
John,

From: I2nsf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner
Sent: Sunday, December 06, 2015 7:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

<Snipped>

Critical Problems:

4. Recommendations

5. Origin of PCIM/PCIMe

regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 13 Dec 2015 21:27:21 -0800

Hi Frank,

Since current design principle for the policy model of capability interface
is to abstract from most common existing NSF security policy
implementations and consolidate them into a general and extensive model, I
think imperative logic is more suitable for this goal.

<jcs>
I agree. For example, declarative policies will require a much more complex
translation to a form that security devices can ingest than imperative
policies do.
</jcs>

I am very interested in whether “event” can be used in I2NSF capability
interface. Do you have some suggestions?

<jcs>
Why not? :-)
There are a lot of advantages to using Events. For example, events can be
used to debug the system by providing a real-time trace of which policies
executed. Logs like this are also crucial for accounting and auditing.
I think that we should at least make Events (and hence,
event-condition-action policies) optional in our policy structure.
</jcs>

Are the “subject” and “target” two different classes in PCIMe? Do you
suggest to include them in I2NSF policy model of capability interface for
the goal of authorizing the policy?

<jcs>
Subject and Target are NOT part of PCIM or PCIMe (see Post 2a or 2b).
IFF I2NSF needs to represent authorization policies (and I don't see why we
wouldn't), then SUBJECT is MANDATORY; it is also mandatory for performing
deontic and/or alethic logic.
Target (especially if modeled as a set of roles) is a much more scalable
and robust way of defining what entities policy will be applied to.
</jcs>

regards,
John

On Sun, Dec 13, 2015 at 6:45 PM, Xialiang (Frank) <[email-masked]

> Hi John,
>
> Since current design principle for the policy model of capability
> interface is to abstract from most common existing NSF security policy
> implementations and consolidate them into a general and extensive model, I
> think imperative logic is more suitable for this goal.
>
>
>
> Are the “subject” and “target” two different classes in PCIMe? Do you
> suggest to include them in I2NSF policy model of capability interface for
> the goal of authorizing the policy?
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人:* I2nsf [mailto:[email-masked]] *代表 *John Strassner
> *发送时间:* 2015年12月12日 7:32
> *收件人:* Linda Dunbar
> *抄送:* [email-masked]
> *主题:* Re: [I2nsf] Service Layer Policies - Post 1: Background Information
> on PCIM
>
>
>
> Hi Linda,
>
>
>
> ·  Most of the classes that are used to implement the relationships
> 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>
>
>
>
>
>
> 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
>
>
>
>
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 14 Dec 2015 19:50:58 -0800

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) <
[email-masked]> wrote:

> Hi John,
>
> Firstly, thanks for raising this valuable discussion about I2NSF policy
> model. It’s really useful to our interface information model drafts.
>
> *发送时间:* 2015年12月11日 4:43
> *收件人:* Linda Dunbar; John Strassner
> *抄送:* [email-masked]; Natale, Bob
> 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
>
>
>
> [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.
>
>
>
> [Frank]: This context-aware policy rules make sense for I2NSF in my
> opinion. Are you going to introduce it into I2NSF?
>
>
>
> regards,
>
> John
>
>
>

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 15 Dec 2015 07:11:34 +0000

Hi John,
It’s great you can join the work of capability interface information model I-D.

B.R.
Frank

发件人: John Strassner [mailto:[email-masked]]
发送时间: 2015年12月15日 11:51
收件人: Xialiang (Frank); John Strassner
抄送: Linda Dunbar; [email-masked]; Natale, Bob
主题: Re: 答复: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

Hi Frank,

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

<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) <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] 代表 John Strassner
发送时间: 2015年12月11日 4:43
收件人: Linda Dunbar; John Strassner
抄送: [email-masked]<mailto:[email-masked]>; Natale, Bob
主题: Re: [I2nsf] Service Layer Policies - Post 1: Background Information on PCIM

Hi Linda,

   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

regards,
John

Linda

Hi Linda,

You asked:

John,

<Snipped>

Critical Problems:

4. Recommendations

5. Origin of PCIM/PCIMe

regards,
John

--
regards,
John

--
regards,
John