Subject: Re: FW: Review of the Policy VISIO and Discussion on PolicyGroup

From: [email-masked]
Date: Wed, 29 Sep 1999 10:45:58 -0400

Andrea,

Thanks for the comments.  See my responses below.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Andrea Westerinen (Exchange)" <[email-masked]> on 09/28/99
08:22:04 PM

To:   "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>
cc:
Subject:  FW: Review of the Policy VISIO and Discussion on PolicyGroup

> Since Bob, John and Ed are publishing new Core Model drafts on Monday, I
> thought that I'd better do some reviews. :-)
> Here are some comments and questions on the Core Model VISIO:
>
> 1. How do you envision that the keys working?  It seems that PolicyGroup
> and PolicyRule have only 1 key (a name string) but that Rules are weak to
> Systems.  Shouldn't Groups be weak as well?  If indeed Rules are weak to
> Systems then you need the System keys (CCN + Name) propagated to Rule.
>
I'm fine with making PolicyGroup weak to System, in the same way that
PolicyRule is.  As for the propagated keys, they'll be there in the MOF
when I create it.  The CIM convention seems to be not to show propagated
keys in the Visio, though.

> 2.  PolicyConditions and PolicyActions are defined (essentially) weak to
> Rules (without actually being weak to them) and with CreationClassNames.
> Why is there no consistency with Rule/Group keys related to CCN?  Why
> aren't Conditions/Actions weak to Rules, which yields the same key
> structure as what you have listed?
>
> 3.  Have we given up on Condition/Action reuse?
>
I'll respond to 2 and 3 together.  We definitely haven't given up on
reuse of PolicyConditions and PolicyActions.  In fact, we're now making
explicit a semantic distinction between rule-specific Conditions and
Actions versus reusable ones.  It's only the rule-specific ones that
are named within the context of a PolicyRule.  Reusable Conditions and
Actions are named within the context of the PolicyRepository (a new
subclass of AdminDomain) where they live.  So, we're faced with a
structure that CIM doesn't really handle:  a particular instance of
PolicyCondition or PolicyAction is "weak" to *either* a PolicyRule or
a PolicyRepository.  (LDAP, or course, handles this just fine, since
a class can have multiple classes as possible DIT superiors.)

The full instance naming for a PolicyCondition or PolicyAction, then,
works like this in the two cases:

Rule-specific:
   - SystemCCN  (looks just like it's propagated from PolicyRule, but
                 it's not)
   - SystemName (looks just like it's propagated from PolicyRule, but
                 it's not)
   - PolicyRuleName (looks just like it's propagated from PolicyRule,
                 but it's not)
   - PolicyConditionName or PolicyActionName

Reusable:
   - SystemCCN  (looks just like it's propagated from PolicyRepository,
                 but it's not)
   - SystemName (looks just like it's propagated from PolicyRepository,
                 but it's not)
   - PolicyRuleName (some sort of null value -- maybe a zero-length
                 string?)
   - PolicyConditionName or PolicyActionName

As for why we don't have CCN for the Policy classes, we determined
in Austin that (1) we don't really need CCN since we have the
class-specific key properties, and (2) CCN doesn't really work anyway,
since it prevents an instance from "upgrading" to a subclass as
additional properties come to be (or come to be known?) for it.

> 4. How does the AdminDomain object fit into this?  I understand that
> policies are created by/for administrators.  But, to define the
> rules/actions/conditions according to this "process" seems more an
> artifact of the LDAP mapping than a good modeling approach.  I would
> rather see the two abstractions (Core CIM and LDAP) diverge, with a
> mapping between them, than force naming/LDAP issues into the model.
>
I'm not sure I've understood your question, but I'll try to respond
anyway.  In a networking case, I'd expect the System that scopes a
PolicyRule (and, given my response to item 1 above, a PolicyGroup as
well) to be the AdminDomain that represents the set of network resources
to which the policy applies -- a subnet, an autonomous system, etc.
For policies that apply to a server, the System would probably be a
ComputerSystem representing the server.  The same relationship
that ties a ResponsibleEntity to a System would indirectly tie the
ResponsibleEntity to the policy objects for that System.

For reusable Conditions and Actions, the PolicyRepository (subclass of
AdminDomain) can still be tied to an administrator via the
ResponsibleEntity / System relationship that PolicyRepository inherits
from System.

I'm not sure how you see this as forcing naming/LDAP issues into the CIM
model.  We certainly didn't think of the semantic distinction between
rule-specific and reusable Conditions and Actions as being in any way
an artifact of LDAP.  Even if there were no directory mappings to worry
about, we'd still want to make this distinction in the CIM model.

> 5.  I thought that the purpose behind PolicyGroups was to group the Rules
> administered by a single entity (person, role, organization, whatever).
> If so, why doesn't AdminDomain associate to Groups?
>
If I've understood your question, the answer is that having made
PolicyGroup weak to System, we now have the association you want via the
System / ResponsibleEntity relationship I discussed above.

>
> Also, I have two requirements for rule processing - to be able to
> breakdown rules from higher level to lower level (perhaps more concrete)
> rules and to describe the set of policies that apply to an entity at a
> particular point in time.  The first is not addressed by the model today
> and the second may be.
>
> To clarify this, could we ...?
> 1.  Create an aggregation from PolicyRule to PolicyRule - to let me
> describe rule breakdown (similar to the ServiceComponent aggregation in
> the Core Model)
This is getting into a discussion we started last week at the Network
WG meeting in Concord, and that will continue on our Wednesday DMTF
mega-calls and at the Network / Policy / User / LDAP Mapping WG meetings
in Portland.  In Concord we started thinking about breaking a PolicyRule
down into Configuration / Setting objects, as a way of representing the
"magic" that takes place at a Policy Consumer (PDP) when it translates
a PolicyRule it got from the Repository into a form that its Policy
Target (PEP) can understand.  Even if we end up going this way, though,
that still doesn't rule out a mapping at a higher policy "layer" that
takes a high-level rule and breaks it down into lower-level rules,
which are subsequently mapped to Configuration / Setting objects.

By the way, since both of these translations can be thought of as
taking place *within* components of the Policy Framework, I don't see
them as falling within the scope of our IETF / LDAP work.  Thus in
this particular case it's fine for us to be doing the work of defining
these relationships in the DMTF / CIM arena.

Al, since you own the Configuration / Setting submodel in the Network
WG, I've copied you explicitly, to make sure you stay up to speed on
this particular topic.

> 2.  Lighten up on the definition of a PolicyGroup as related "only" to
> administration of rules.
>    If related to admin, then there would be an association to
> AdminDomain.
>    If used to define a set of policies that apply to an entity, then
> the GroupWithXXXJurisdiction exists.
>    Perhaps properties could be added to the PolicyGroup object to
> convey this semantic clearly
>         - ie, AdministrativeGrouping boolean and
> SetOfApplicablePolicies boolean

We can talk about this further, but my initial reaction is that if we
need a class to represent an operational grouping of PolicyRules
as opposed to an administrative grouping, then I'd rather see it be a
different class (maybe a subclass of Collection?) rather than a new
application of PolicyGroup.  I think your booleans would be doing
essentially the same thing in a less direct way.  Also, having
separate classes would simplify the LDAP mapping, since, I assume,
we would want to have the administrative groupings stored in the
directory, but not the operational ones.
> Andrea