Subject: Re: PCIM Extensions

From: "Robert Moore" <[email-masked]>
Date: Thu, 18 Jan 2001 09:26:16 -0500

Mahadevan,

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.
In fact, the first example cited (Backbone interface) was
supposed to represent an administrative category, to be
contrasted with the functional one represented by the
second example (Frame Relay interface).  Since this
distinction apparently didn't come across clearly, we can
look at choosing some better words.

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.

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.

Regards,
Bob

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

Yoram Ramberg <[email-masked]>@raleigh.ibm.com on 01/18/2001 07:01:19
AM

Please respond to Yoram Ramberg <[email-masked]>

Sent by:  [email-masked]

To:   Mahadevan Iyer <[email-masked]>, Lee Rafalow
      <[email-masked]>, [email-masked]
cc:
Subject:  Re: PCIM Extensions

[...snip...]
 >
> > >   3. There needs to be a means to formally specify
> > the
> > > policy target(some overlap with the enforcement
> > > domain) in the policyrule. I am looking for
> > something
> > > that is stronger than a policy condition variable
> > > type. The logic that led to the creation of
> > > "PolicyTimePeriodCondition", instead of adding a
> > > policy condition variable type, could be applied
> > out
> > > here.
> >
> > What are the functions you're looking for that are
> > not provided by
> > PolicyRole?
>
>The PolicyRole from [PCIM]
>=======================
>Using the roles and role-combinations it received from
>its PEPs as
>       indicated in the examples above, the PDP is able
>to locate and
>       retrieve the policy rules that are relevant to
>it.
>========================
>
>This is used to indicate a class of consumers e.g "all
>policy enforcers that implement a firewall" should
>pick up policies that have "firewall" mentioned in
>their "PolicyRole" attribute.
>
>This does not address the problem of which of the 10
>firewalls in the network need to download the policy.
>
>This is how I read it, maybe you could tell me how the
>PolicyRole is supposed to be used.
[...snip...]

Ah... Actually, my reading of this is slightly different. However, I have
my problems with that text, which may be also the cause for the apparent
misunderstanding. The following text from PCIM seems to imply what you
said:

   "A role represents a functional characteristic or capability of a
    resource to which policies are applied.  Examples of roles include
    Backbone interface, Frame Relay interface, BGP-capable router, web
    server, firewall, etc. "

However, this is quite restrictive and unnecessary. Furthermore, it is not
(IMO) the intention of the authors at all!.
I think of a role as a mapping mechanism between policies and their
targets. The above text represent an example where roles are used to map
policy to objects that have some "functional characteristics" such as
"Backbone interface", etc. However, these are just names, nothing more.
"Frame Relay" may be a role name and the mapping of a given policy using
this role *may be* interpreted by a (a very smart) PDP to frame relay
interfaces. Another usage for role will be "VPN1-Ingress". This is, yet
again, a name. How to assign this name to actual network elements is way
outside the scope of PCIM. Within a given network, the 'VPN1-Ingress' role
may be assigned to a bunch of interfaces determined to be serving in this
role. Some of those may be actually frame relay while others may be ATM and
maybe even virtual tunnel interfaces or what have you. No requirement is
placed on a semantic mapping from the value of the role name to a member in
a set of network elements carrying this role.
This means that the mapping you desire is exactly what roles do. This also
means that the text you're referring to in PCIM is somewhat misleading.

Bottom line: The role *may* represent a functional characteristic. It may
also represent more or less than a functional characteristic, say a
functional characteristic and an administrative purpose.

One more thing about this example: The text also says that the roles are
received from the PEPs. This is true only when the PEPs and PDPs use COPS
to inter-communicate. Notwithstanding the PEP/PDP terminology, this is not
only the case. Indeed, this is still the minority case in the real world to
date. I'm just saying this lest further confusion is created by that text.

*Yoram

---

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 23 Jan 2001 01:33:49 -0800 (PST)

--- Yoram Ramberg <[email-masked]> wrote:
> that specific domain policy targets can be modeled
> as a derivative of the 
> "core" policy target model.

Nevermind "domain specific", what I am looking for is
a commonly understood placeholder for policy target.
If tying this to some thing bigger is going to slow
things down(charter etc), then I would rather see a
simple extension.

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

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

Precisely, this request has been addressed to the
group working on PCIM extensions. Once again my
request is that we standardize these extensions of the
PolicyRole.

Thanks 

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