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

From: [email-masked]
Date: Thu, 30 Sep 1999 09:10:15 -0400

Andrea,

Look for the <Bob> ... </Bob>'s this time.

Regards,
Bob

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

"Andrea Westerinen (Exchange)" <[email-masked]> on 09/29/99
04:17:59 PM

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   "[email-masked]'" <[email-masked]>,
      "[email-masked]'" <[email-masked]>, [email-masked]
Subject:  RE: FW: Review of the Policy VISIO and Discussion on PolicyGroup

Comments on comments.  I think that we are close here except on CCN.  And,
there are some more questions.

Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 29, 1999 7:46 AM
To: Andrea Westerinen (Exchange)
Cc: [email-masked]'; [email-masked]';
[email-masked]
Subject: Re: FW: Review of the Policy VISIO and Discussion on
PolicyGroup

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.

[arw] Thanks, consistency is a Good Thing.

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

[arw] It seems that you still have a problem, however, since PolicyRuleName
is still a key property in the VISIO.  Whether or not you have the weak
qualifier on the association to PolicyRule - you still have a key property
name.  Is your intent to have a standard string inserted into this property
if the Condition/Action are reusable?
<Bob>
Yes, that's exactly what we're trying to do.  But I haven't been able
to find out whether my first choice for this standard string, the
zero-length string, is a legal value for CIM's string datatype.  Do you
know whether this is legal?
</Bob>

[arw] And, a couple more questions:
1.  Why wouldn't you make Conditions and Actions at least weak to Systems,
as Rules are?
<Bob>
I suppose we could, but that makes the model harder to understand
and explain, and I'm not sure what it would buy us.  I'm not sure
whether you're proposing that we add a weak aggregation
PolicyCondition(Action)InSystem, or replace the existing aggregation
Condition(Action)InPolicyRepository with this weak aggregation.
Either way, I think it would be hard to explain what's going on,
hard to implement, and harder to do the mapping to LDAP.  For example,
if I wanted to create a rule-specific PolicyCondition, how would I
know which instance of System to make it weak to?  Answer:  I'd go
look at the System keys that had been propagated into the PolicyRule.
But if I'm going to have to do this anyway, and if I'm having to copy
the value of the PolicyRule's third key (PolicyRuleName) into the new
PolicyCondition anyway, why not just copy the other two key values as
well?

Summary:  unless there are some big gains we'd get from making
PolicyCondition and PolicyAction weak to System, I'm inclined to
leave things as we have them now.
</Bob>

2.  Why are Conditions and Actions aggregated into AdminDomain versus Rules
aggregated into the higher level Systems?  I would think that these are 2
sides of the same coin and should look/act similarly.
<Bob>
The idea is that the units of reusability are PolicyConditions and
PolicyActions, not PolicyRules.  This will be clearer in the upcoming
version of the Visio and document, with the addition of a new subclass
of AdminDomain named PolicyRepository, to participate in the
aggregations.
</Bob>

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.

[arw] Could you clarify what "class-specific" keys are since I don't
understand how you fix the CCN problem.
<Bob>
Class-specific keys are just PolicyRuleName, PolicyConditionName, etc.
They're not literally class-specific, since they're inherited by
subclasses of the Core Policy classes.  But they're also not like
a property such as Name, which appears in multiple peer classes in the
inheritance hierarchy.  So the thinking is that if all PolicyActions
in a given naming context are given unique values for the property
PolicyActionName, regardless of whether they are instances of
PolicyAction itself or of one of its subclasses, then that property
alone is enough to insure unique naming.
</Bob>

                                         Regarding your second point, I
totally disagree.  CCN doesn't prevent upgrading to a subclass since it's
definition is NOT tied to the class name directly.  If you look at the
writeup for the property, its sole use is to limit the scope of uniqueness
for keys, when the keys are defined at a high level in the object hierarchy.
So, if you can name all LogicalDevices devices uniquely - starting from
CIM_LogicalDevice and going down the tree - you can put CIM_LogicalDevice in
the CCN.  If, however, you have to go down to StorageExtents and DiskDrives
to get name uniqueness, then you can put CIM_StorageExtent or CIM_DiskDrive
in CCN.  Since this is only a string WITH some semantics, it works.

[arw] Also, I don't totally understand the upgrade issue.  If you create a
concrete instance of a class X and then decide that it is really an instance
of a subclass Y - in some implementations, you may need to delete the first
instance and create the second.  In other implementations, you could just
"extend" - but CCN would still be ok as previously set - since it is for
name uniqueness ONLY.
<Bob>
I'm not sure what to do when the CIM experts disagree.  With regard to
your last sentence, though, I'll say that that's not how I read the MOF.
Here's a section from the CIM 2.2 Core MOF for CIM_PhysicalElement:

       [Key, MaxLen (256), Description (
         "CreationClassName indicates the name of the class or the "
         "subclass used in the creation of an instance. When used "
         "with the other key properties of this class, this property "
         "allows all instances of this class and its subclasses to "
         "be uniquely identified.") ]
    string CreationClassName;

The second sentence is talking about name uniqueness, but the first
sentence seems clearly to be talking about something else.  I'm not
sure what else, since I'm not sure how to interpret "...used in the
creation of an instance."  But it's something more than just naming.
</Bob>

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

[arw] OK, got it.  So, I am more convinced that Conditions and Actions are
weak to Systems - like Rules.  In your first example, they apply to the
Repository.  In your second example (of a server), they apply to the Server.

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

[arw] Yes.

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

[arw] Did we have a call today?  If so, I didn't get a phone number or
anything.  Could we post these on the Policy/Networks WG web site of the
DMTF?
<Bob>
No, we didn't have a call -- it seems to be difficult for the chairs
of the affected WGs to get together to decide what to do on the call
each week.  I'm pretty sure there will be a call next week, since we
really need to get on the same page before we go to Portland.

I'm not sure about posting call arrangements on the DMTF web site.
My impression is that there's a lag in that process that's not present
when the arrangements are just sent out to the WG mailing lists.
</Bob>

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.

[arw] We need to be careful here since this is a generic class hierarchy.  I
don't believe that all rules can be broken down into Config/Setting objects.

[arw] Also, I'm not clear, was your answer "OK to add" or "not OK"?
<Bob>
My answer was definitely not "OK to add right now."  We need to think /
talk about all of this quite a bit more.
</Bob>

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

[arw] Works for me.  Will you add this to the VISIO?
<Bob>
I'd also like to hold off on this addition, although I don't think it's
as big an issue as the previous one.  I'm not sure you and I are
thinking about exactly the same thing when we talk about this new
class, since I don't see it being tied in with the group jurisdiction
concept.
</Bob>
> Andrea

---

From: "John Strassner" <[email-masked]>
Date: Mon, 4 Oct 1999 23:49:01 -0700

comments inline, starting with point 2. see <jcs>...</jcs>

regards,
John
----- Original Message -----
From: <[email-masked]>
To: Andrea Westerinen (Exchange)
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, September 30, 1999 6:10 AM
Subject: RE: FW: Review of the Policy VISIO and Discussion on
PolicyGroup

> "Andrea Westerinen (Exchange)"
<[email-masked]> on 09/29/99
> "Andrea Westerinen (Exchange)"
<[email-masked]> on 09/28/99
> know whether this is legal?

<jcs> From the CIM specification:
"Any properties not initialized will have default values as
specified in the class definition, or (if no default value has
been specified) the special value NULL to indicate 'absence of
value'. "

However, this doesn't work, since this is a key property, and
they can't be null for obvious reasons. But before we try
redesigning it, there are other problems:

Why do PolicyAction and PolicyCondition have SSN and SN
properties? They aren't (directly) weak to a system as you've
described, they are weak to either a PolicyRule or a
PolicyRepository. So in the case of the reusable object, this
doesn't work, because this property is already the key of the
weak relationship. Furthermore, I don't think that they should be
directly weak to a system. This would imply that the System hosts
the PolicyCondition/Action, and that isn't correct - it is the
PolicyRule or the PolicyRepository that hosts the
PolicyCondition/Action.

In addition, the property PolicyRuleName should NOT be copied
into these subclasses, because this is part of the weak
relationship. Except that if it is reusable, you can't make it
null. So I guess it shouldn't be there at all.

So what do we do? Well, there is a weak relationship between
PolicyRule and System, and there is a weak relationship between
PolicyRepository and System. What we want to express is extending
this weak relationship to include PolicyCondition and
PolicyAction. An example is provided in the System modek, where
we have Threads being weak to Processes, which are in turn weak
to OperatingSystems, which are in turn weak to ComputerSystems.

So I think what we want to do is to define two explicit weak
relationships, instead of trying to glom them together. For the
non-reusable case, change ConditionInPolicyRule and
ActionInPolicyRule to weak relationships (e.g., PolicyCondition
and PolicyAction are each weak to PolicyRule). For the reusable
case, define TWO ADDITIONAL weak relationships (e.g., make
ConditionInPolicyRepository a weak relationship {PolicyCondition
is weak to PolicyRepository} and make ActionInPolicyRepository a
weak relationship).

Granted, this looks a bit odd. But remember that this is not an
instance model, but rather a class model, and thus reflects only
the
possibilities. Furthermore, this more accurately reflects what is
happening in the LDAP case. We'll need to explain that in the
MOF.
</jcs>

> leave things as we have them now.

<jcs> Please see the above discussion. The way they are now is,
imho, wrong. </jcs>

> of AdminDomain named PolicyRepository, to participate in the

<jcs> I think that Bob is correct here - the PolicyRepository is
a unit of reusability scoped by a particular AdminDomain. When
these puppies are reused to form PolicyRules, then they will be
bound to a particular System.
</jcs>

>    - PolicyConditionName or PolicyActionName

<jcs> I don't think that this works (see above discussion). In
the rule-specific case, the PolicyCondition/Action is weak to a
PolicyRule, which is in turn weak to a System, which is not what
you have. Similarly, in the reusable case, a
PolicyCondition/Action is weak to a PolicyRepository, which is a
type of system (AdminDomain). However, this is somewhat
misleading, because PolicyConditions/Actions that are stored in a
PolicyRepository won't form a policy directly - rather, they will
be attached to a PolicyRule.
</jcs>

> I'm not sure what to do when the CIM experts disagree.

<jcs> Which CIM experts? </jcs>

> With regard to

<jcs> The Creation Class Name property indicates the concrete
class/subclass used in the creation of an instance. It allows me
to differentiate between different subclasses of, for example,
CIM_System, that were used to create an instance. So I think that
Andrea is right in both issues here. CCN has nothing to do with
the NAME of the class, it has everything to do with the TYPE of
the class. Furthermore, its whole raison d'etre is to
differentiate between subclasses, so when you upgrade, the CCN
will change.
</jcs>

> Repository.  In your second example (of a server), they apply
to the Server.

<jcs> No, still disagree - see my writeup above. Conditons and
actions are not weak directly to systems, this would mean that
the system hosts them, wich it doesn't. They are ultimately
hosted by a PolicyRule.
</jcs>

> > particular point in time.  The first is not addressed by the
model today

<jcs> Andrea, for the first, are you asking that a PolicyRule
contain another PolicyRule? I'm not sure I like this one. First,
it moves us away from being a declarative system. Second, where
do you put the (gasp) "embedded" PolicyRule - as a part of the
condition or action? If you choose either, this breaks the
semantics that we have spent trying to build. I'd rather not do
this.

For the second, I'm not sure. I think we do, using the
PolicyTimePeriodCondition class - what is lacking?
</jcs>

> > 1.  Create an aggregation from PolicyRule to PolicyRule - to
> > let me describe rule breakdown (similar to the
> > ServiceComponent aggregation in the Core Model)
...

<jcs> I'd rather not. We have strictly defined semantics right
now - a policy rule is a set of conditions and a set of actions.
If you try and make policy rules contain policy rules, we start
over. </jcs>

...

> which are subsequently mapped to Configuration / Setting
objects.

<jcs> Correct, this would end up being separate associations, not
embedded policy rules. </jcs>

> don't believe that all rules can be broken down into
Config/Setting objects.

<jcs> Andrea, while I agree with you, I also have to consider the
needs of the IETF. Right now, our focus is explicitly on
networking QoS policy.

If the DMTF wants to extend this, then that's fine. And the DMTF
can add to this document to their heart's content. But this is an
IETF document, and should remain focused on networking QoS.
</jcs>

> class, since I don't see it being tied in with the group
jurisdiction

<jcs> I'd like to hold off on this too. These are new ideas, and
we don't have a NETWORKING use case for operational
grouping yet. Again, we need to separate the CIM modeling
of generalized ideas from the more focused set of IETF
requirements. And right now, I don't want to complicate the
IETF model further. </jcs>