Subject: Re: PCIM Extensions

From: Mahadevan Iyer <[email-masked]>
Date: Mon, 22 Jan 2001 01:42:14 -0800 (PST)

--- Robert Moore <[email-masked]> wrote:
> Yoram is correct.  The intent of roles / role
> combinations
> all along was to allow the values to provide
> functional
> categorization, or administrative categorization, or
> both.

I feel it would be important to standardize the
policyTarget, since most external interactions (with
PEP's, PDP's etc) will benefit from it. The
policyTarget would map to a special kind of role as
described later.

> First, though, as part of the PCIM Extensions work,
> we're
> planning to re-examine the question of whether
> PolicyRoles
> is defined correctly in the first place.  Within the
> basic
> concept of roles / role combinations as a vehicle to
> allow
> policy rules to be associated with the resources to
> which
> they apply, there's room to ask whether a single
> property
> that combines functional and administrative
> categorization
> into one set of selectors is the best way to do it.

I would suggest that we further refine PolicyRoles
into AdministrativeRole, FunctionalRole and
EnforcementRole. If Roles are going away then the
replacement could provide the equivalent refinement.

The PolicyTarget could map to the EnforcementRole.
 
> A second question we need to examine is the
> relationship
> between policy roles and policy conditions, since
> both of
> them are true of a resource when a policy action is
> performed.  For example, if it's true (long term)
> that an
> interface is Frame Relay, and it's true (right now)
> that the interface is congested, then some action to
> address the congestion will be performed.  We had
> thought
> that there was a clear distinction between these
> long-
> term truths (represented by policy roles) and the
> more
> passing one (represented by policy conditions).  But
> the
> initial work in the SNMPconf WG has started from the
> opposite viewpoint, that there is no relevant
> distinction
> between these two types of truths.

I don't see the issue here, looks like the (condition
+ role) should handle the combinations supported by
the work in the SNMPconf WG.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

---

From: Yoram Ramberg <[email-masked]>
Date: Mon, 22 Jan 2001 14:13:42 +0200

Inline.
*Yoram

>policyTarget would map to a special kind of role as

Maybe. I think there might be an issue with this. Policy target is probably 
somewhat standardized in the network model. In DiffServ there is a notion 
of policy target although it might not be so termed. In COPS there's a 
notion of PEP. I'm sure IPSec and MPLS have their own concepts of policy 
target. If I were to approach this from an information modelling angle 
within the Policy WG, I'd take this approach:

First, of course, I'd construct an argument to justify an inclusion of such 
work in the WG's assignment list... the charter may need to be revised to 
explicitly specify a deliverable for this.
Now, a policy target may end up being an object with some policy 
capabilities. Policy capabilities are tricky to model and must be done so 
that specific domain policy targets can be modeled as a derivative of the 
"core" policy target model. Interesting. Maybe this will lead to the long 
awaited QoS capabilities info model...

>The PolicyTarget could map to the EnforcementRole.

See, this can lead to an over-design. While you're certainly aiming right, 
you're simply charting out a great example forr deriving useful mapping 
mechanisms using PCIM. I haven't looked, but maybe all you're asking for is 
allowing the PolicyRole to be a class that one could further refine by 
derivation. Now, about PolicyTarget being EnforcementRole -- as I said 
above, I have a hunch that this might develop into a richer concept 
deserving its own modeling efffort.

>the work in the SNMPconf WG.
Frankly I don't think the difference between eternal truth and other truths 
is to be modeled at the level of core. You might then bring this ad 
absurdum by requiring a condition on this very property of the truth as in:
"If <Cond> is true AND the truth of Cond is eternal, then ..." clearly this 
is verging on the ridiculous. I suppose in some special cases the notion of 
an interface being Frame Relay is meaningful, but in general, a good 
abstraction of the policy target should remove the dependency on a target 
being Frame Relay. Rather, a class with set of capabilities/attributes 
(possibly called "FrameRelay") is a better approach as it is very 
refineable and extensible (is this a redundant sentence?).

>Thanks

Yea, me too.
*Yoram