Subject: RE: Policy issues: definition of Roles

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 26 Jan 2000 14:16:31 -0500

I fear we are on different wavelengths. Perhaps it is just terminology. Can
you tell me what you mean by "client types" in your last comment?

Thanks,

-Walter 

> -----Original Message-----
> From: Jon Saperia [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 1:14 PM
> To: Weiss, Walter
> Cc: [email-masked]
> Subject: Re: Policy issues: definition of Roles
> 
> 
> "Weiss, Walter" wrote:
> > 
> > Jon (Saperia),
> > 
> > Are you suggesting that a given policy should be restricted 
> to a single
> > class (the policy equivalent of a PIB/MIB row) and that a
> > collection/hierarchy of policies be used to implement the 
> example policies I
> > cited?
> > 
> > regards,
> > 
> > -Walter
> 
> Actually no - I do not think that all policies must necessarily be
> limited to a single class. I think there should be a class of policies
> which can span what you would call single client types.  I 
> had mentioned
> this a while ago.  It seems logical to me that in some cases policies
> are modified by others. It is possible that a collection of policies
> could reasonably be implemented as a hierarchy or in other
> relationships. It might be fun to use something like rational rose to
> model real world policies and see the relationships and 
> shared data elements.
> 
> /jon
>

---

From: Jon Saperia <[email-masked]>
Date: Thu, 27 Jan 2000 06:22:25 -0500

> you tell me what you mean by "client types" in your last comment?
Sure, that is one of the problems in work like this. What I mean by
client types are for example, a COPS differentiated services client type
or a security client type - that that has not been talked about as much.
My point being that in some cases it is helpful for 'policy' to cross
what has come to be accepted as clear divisions of function. I might
want my quality of service policy to be modified by an outage policy
which says that if the case of a failure, which of the 32 policies for
quality of service (where policy in this case translates to a customer)
do i want to 'protect' and which am I willing to sacrifice.  In this
sense, under some conditions a policy is modified by another policy.

In my view it is not possible to effectively write a policy that covers
every possible interaction so some will have to interact.

/jon

---

From: Shai Herzog <[email-masked]>
Date: Thu, 27 Jan 2000 17:04:58 -0500

>every possible interaction so some will have to interact.

I tend to agree. I think this is the reason for the Client-Type
separation, however it is important to note that this limitation
is one for the PEP only, and not for the PDP. While we can't
predict and write all combination of standard policies that
cross client type boundaries, the PDP in its "proprietary logic"
could figure out what to do and send it to the PEP as two sets
of instructions, one for each client type. (This is where the
differentiation factors between vendors may spark ingenuity.)

As for the definition of Roles, I hate to say it, but I think that
neither 1 or 2 are true definitions because they are tied down to
specific implementation (PIB/Rule binding, etc.).
I think that a Role is a more general concept and the definition
should reflect it. Perhaps a definition should look something like:

"A Role represent an attribute of a network node or an interface
that reflect physical or logical functionality. Those attribute may be
used by policy systems to determine the appropriate policy that
should be constructed for that node or interface."

And role combination:

"A set of one or more Roles that are grouped together as a basic
atomic unit for which policy instructions are needed".

What do you think?

Shai

__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006

---

From: Bob Natale <[email-masked]>
Date: Fri, 28 Jan 2000 00:55:03 -0500

At 1/27/2000:05:04 PM, Shai Herzog wrote:

Hi Shai,

><...>
>should reflect it.

I agree (true of most defintions in efforts such as these).

>Perhaps a definition should look something like:
>

I like them, except that I would change "A Role represents an
attribute of a network node or an interface..." to "A Role is
a representation of a policy target..." or "...of a policy
object..." or some other similar generic abstract term.  I would
try to avoid pining the language to specific device types or
categories (esp. since software entities might also be the
targets of policy enforcement).

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: Michael Fine <[email-masked]>
Date: Fri, 28 Jan 2000 00:00:17 -0800 (PST)

> should be constructed for that node or interface."

I agree completely.  I do not understand either of the original
definitions.  But this definition captures precisely my understanding
of a role.

To be repetitive, a role simply represents some attribute or
characteristic of some (logical or physical) network entities.  It
stands on its own independent of any policy system, PIB or MIB.  The
PIB happens to make use of roles to bind policy to network entities
without specifying those entities explicitly.

 > atomic unit for which policy instructions are needed".

Here I differ.  A role combination, in my mind, is simply the set of
roles of a network entity.  Again it stands on its own, independent of 
policy, PIBs, MIBs.

In the PIB we happen to associate role combos with units of policy and
made the rule that a unit of policy is applied to a network entity
if and only if the role combo of the policy and that of the entity are
identical.  But we could have made some other rule; for instance the
rule could be that the role combo of the policy be a subset of the
role combo of the entity.

 > targets of policy enforcement).

I agree that node and interface is too restrictive.  But I don't agree 
with the alternative "A role is a representation of a policy target".
Can't we just replace node and interface with the nebulous "entity".

Michael

---

From: Bob Natale <[email-masked]>
Date: Fri, 28 Jan 2000 07:46:40 -0500

At 1/28/2000:03:00 AM, Michael Fine wrote:

Hi Michael,

>roles of a network entity.  Again it stands on its own, independent of 

Hmmm.  I can see where a given role combination *could* be *the* set
of roles applicable to one or more entities..but more commonly would be 
some *subset* of the range of roles applicable to one or more entities...?

>role combo of the entity.

Yes....I think your last sentence in that paragraph addresses my
concern here.

>Can't we just replace node and interface with the nebulous "entity".

Yes, that would be an improvement (IMHO) that would suffice for me.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Shai Herzog <[email-masked]>
Date: Fri, 28 Jan 2000 09:25:33 -0500

Given the feedback, here's a second version:

"A Role represent an attribute of a logical or physical network entity
that reflects some functionality. Those attribute may be used by
policy systems to determine the appropriate policy that
should be constructed for that network entity"

And role combination:

"A set comprising of all the Roles associated a single network entity".

Shai

---

From: "Jon Sjoberg" <[email-masked]>
Date: Fri, 28 Jan 2000 10:24:55 -0500

This, in my opinion, is the best yet.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Shai Herzog
> Sent: Friday, January 28, 2000 9:26 AM
> To: Michael Fine
> Cc: Jon Saperia; Weiss, Walter; [email-masked]

---

From: "Jon Sjoberg" <[email-masked]>
Date: Fri, 28 Jan 2000 10:15:59 -0500

> should be constructed for that node or interface."
Or :
"A Role represents an attribute of a network element that reflects physical
or logical functionality...should be constructed for that network element."
An element could be as low level as an interface or as high level as a
firewall.  In fact, it seems that a high level role could be defined by an
aggregation of role combinations.

---

From: Bob Natale <[email-masked]>
Date: Fri, 28 Jan 2000 11:13:55 -0500

At 1/28/2000:09:25 AM, Shai Herzog wrote:

Hi Shai,

>should be constructed for that network entity"

That's good.

>"A set comprising of all the Roles associated a single network entity".

I cannot understand the inclusion of "all" here...can you explain the
rationale to me?

I also cannot understand the significance of the "single" qualifier
in that defintion either...?  Am I wrong in thinking that a major
purpose of "Role" is to abstract entity-specific functionality into
some more generic policy-addressable functionality which might apply
uniformly to a set of entities that might implement the functionality
in (possibly) different, entity-specific ways...?

Alternatively, what's wrong with the following definition for
"Role Combination":

"A set consisting of two or more other Roles."...?

Then, of course, those who might be suggesting that no definition
for "Role Comibnation" is required would be right, since the definition
of "Role" might just as well include the possibility that a given Role
might contain one or more other Roles...?

I will appreciate any explanation of your rationale behind these
two qualifiers ("all" and "single") that you care to provide.
Thanks.

[I hope that at least some of the others on this list are finding
some value in this thread...I feel that I am understanding a
bit more with each message or two...but I can see where this
line of discussion could be seen as tedious to some.]

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 28 Jan 2000 17:35:01 -0800 (PST)

> I cannot understand the inclusion of "all" here...can you explain the

For interfaces, suppose you defined these roles: "Frame-Relay",
"Ethernet", "Backbone", and "Edge-router".  You could then assign both
the "Ethernet" role and the "Backbone" role to a particular interface.
That interface would then have a role combination of "Ethernet"+"Backbone".
If you defined some policies for the "Ethernet" role, and some policies
for the "Backbone" role, then that interface would get the combination
of the policies for "Ethernet" and the policies for "Backbone".

Note that it is advantageous for the system to detect as soon as
possible any conflicts that might exist by applying both the policies
for "Ethernet" and those for "Backbone" to the same interface.  This
can be facilitated by a priori determination of which role-combinations
are valid and which are invalid.  For example, "Ethernet"+"Frame-Relay"
might be invalid and thus, it would not be a problem if there were
conflicts between the policies for "Ethernet" and those for "Frame-Relay".

In order to catch all such conflicts, an interface's role combination
needs to be all the roles that are associated with a particular interface. 

Keith.

PS. When I think of "network entity", I tend to think of a network
device, i.e., it seems strange to me that a router interface would be
called a "network entity".  To overcome this, I would suggest that
"network entity" be changed to "network entity/component".

---

From: Shai Herzog <[email-masked]>
Date: Fri, 28 Jan 2000 22:20:39 -0500

> > I cannot understand the inclusion of "all" here...can you explain the

Keith, you were quicker than me in responding, so I guess I have
little to add ;-) However,...

"ALL" is required since Role Combination goes beyond a "set of
roles". Given a network entity/component with X roles, it's role
combination would be the concatenation of all X roles. The
set of X-1 roles is NOT role combination for this entity.

As for the single, it is related to the "ALL". If you require that
all roles are included, you must also specify the entity the roles
are coming from.

However, it is fine to drop the single and state:

"A set comprising of all the roles associated with a network
entity/component"

>"network entity" be changed to "network entity/component".

Makes sense.

Shai

---

From: Bob Natale <[email-masked]>
Date: Fri, 28 Jan 2000 21:21:42 -0500

At 1/28/2000:08:35 PM, Keith McCloghrie wrote:

Hi Keith,

>of the policies for "Ethernet" and the policies for "Backbone".

Granted.  However, I can imagine, for example, a role called
"Overflow" or some such applicable to interfaces that I would apply
to interfaces.  I migh have policies such as "activaeOverflows"
and "deactivateOverflows" to either turn these on or off as traffic
and/or pricing conditions might warrant.  Makes sense so far...?

If so, then I can imagine that I might have some policies that
apply to the role comibnation of "Ethernet+Overflow" without
necessarily involving the "Ethernet+Backbone" combination --
because it might well also apply to Ethernet interfaces which
did not play the "Backbone" role.  Now, if that also makes sense
(?), how does it mesh with your explanation?

>needs to be all the roles that are associated with a particular interface. 

Ok...I understand your use...however, I don't consider that definition
-- namely, "a role combination is the set of all roles supported by
an entity" -- to be very useful...especially, in the context of trying
to depict a (possibly transient, working) hierarchy of roles (for the
application of one or more policies in any given instance).

I'd suggest using another term, say, "Role Profile" to mean the "the
set of *all* roles supported by an entity" and "Role Combination" to mean
"a set of roles that may be referenced as a unit by a polciy" (or better
words to that effect).  Given that, then every "Role Profile" would by
definition be a "Role Combination", but not every "Role Combination" would
be a "Role Profile".

Am I still off base?  Thanks.

>"network entity" be changed to "network entity/component".

I agree that almost all the terms we try to come up with in this
domain tend to be problematic these days...if just about everything
is part of "the network", then using "network" as a qualifier is
not very helpful.  And, of course, "entity" does much better in
ontological contexts (inside pun for the SNMP community! :-) than
in technical areas.  My original suggestion for "network entity/component"
was "policy target"...meaning anything we could apply a policy to...
which I expect to include way, way more than network devices and
interfaces.  However, I doubt we're going to see consensus form
for something like "policy target", so I will be happy to agree
to your suggestion in this case.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: "John C. Strassner" <[email-masked]>
Date: Sat, 29 Jan 2000 21:50:55 -0800

Comments inline. I'm resisting the urge to respond to the previous messages 
and instead am starting with Bob's reply to Keith's definition, which I 
agree with. The following is an attempt to elaborate on Keith's points. But 
since this is a long note, the key notion that I would like to make is that 
a role is more than "just" an attribute or even a set of attributes. A role 
is a selector that can be used to select one or more policies that are 
applicable to a set of entities or components from a large set of policies 
that are available.

In another note, I would like to work this definition into the basic 
definition that Mike and Keith have put forth.

regards,
John

>(?), how does it mesh with your explanation?

[js] But a role is more than an attribute. A role defines a particular 
function of an entity or component that can be used to identify particular 
behavior associated with that entity or component. So the 
"Ethernet+Overflow" role-combination is different than the 
"Ethernet+Backbone" role-combination. This difference is critical, and is 
most easily understood by thinking of a role as a selector. Thus, 
"Ethernet+Overflow" selects a different set of policies than 
"Ethernet+Backbone" does. So it doesn't matter if you have 
"activateOverflows", "deactivateOverflows", and any other "xxxOverflows" 
policies - you are using the role-combination to select which of these 
applies. So if it makes sense for both of these (and other) Overflow 
policies to be associated with "Ethernet+Overflow", that's fine. If they 
happen to also be associated with "Ethernet+Backbone", that's ok, because 
we are using the role-combination to select the policy, and aren't 
concerned with selecting the policy directly. Though, I would say that in 
this case, the role "Ethernet+Backbone" was named unfortunately.

>application of one or more policies in any given instance).

[js] I disagree. COnsider the case of a repository having thousands of 
policies. Roles and role-combinations are used to select which policies are 
applicable to a set of entities or components. What's important here is not 
depicting a hierarchy of anything. Rather, the purpose is to select the 
small subset of policies that are applicable from a huge set of policies 
that are available.

>Am I still off base?  Thanks.

[js] I'm not sure that Role Profile helps. Profiles generally mean needs or 
requirements of something. For example, a User Profile tells the system 
what services it needs. We're not trying to depict that at all. Roles don't 
represent a need, they are a selector that describes the characteristics or 
functions of an entity or component.

---

From: "Glenn Waters" <[email-masked]>
Date: Sun, 30 Jan 2000 10:27:19 -0500

[js] But a role is more than an attribute. A role defines a particular
function of an entity or component that can be used to identify particular
behavior associated with that entity or component. So the
"Ethernet+Overflow" role-combination is different than the
"Ethernet+Backbone" role-combination. This difference is critical, and is
most easily understood by thinking of a role as a selector. Thus,
"Ethernet+Overflow" selects a different set of policies than
"Ethernet+Backbone" does. So it doesn't matter if you have
"activateOverflows", "deactivateOverflows", and any other "xxxOverflows"
policies - you are using the role-combination to select which of these
applies. So if it makes sense for both of these (and other) Overflow
policies to be associated with "Ethernet+Overflow", that's fine. If they
happen to also be associated with "Ethernet+Backbone", that's ok, because we
are using the role-combination to select the policy, and aren't concerned
with selecting the policy directly. Though, I would say that in this case,
the role "Ethernet+Backbone" was named unfortunately.

[gww] I’m still confused. The way I read the Policy CIM is that a role is
associated with a policy. In one of your examples above you say “…if it
makes sense for both of these (and other) Overflow policies to be associated
with "Ethernet+Overflow", that's fine…” which to me implies that a policy is
associated with a role combination. I can’t figure out which is intended.

How I thought this all worked was that a policy is associated with a role
(or multiple roles). When the policies for a particular role combination are
required then you pick each of the policies that match each of the roles in
the role combination.  So for example, the role combination
“Ethernet+Overflow” would select the “Ethernet” policies and the “Overflow”
policies.

/gww

---

From: Bob Natale <[email-masked]>
Date: Sun, 30 Jan 2000 11:41:42 -0500

At 1/30/2000:10:27 AM, Glenn Waters wrote:

Hi Glenn,

[In the interrest of brevity (uncommon for me!), I'll just
make a short response to Glenn's reaction to John's reply
to my previous more lengthly note.]

>[gww] I m still confused.

That makes two of us.

><...>
>How I thought this all worked was that a policy is associated
>with a role (or multiple roles).
>When the policies for a particular role combination are required
>then you pick each of the policies that match each of the roles
>in the role combination.
>So for example, the role combination Ethernet+Overflow would
>select the Ethernet policies and the Overflow policies.

That's exactly how I understand each of those three points too.

I am only questioning whether "role combination" has to mean the
set of *all* roles supported by a "network entity/component"...the
*all* is the problematic part for me...it just seems that a construct
of "role combination" as *any* valid set of 1 to all roles supported
by a "network entity/component" is a more useful meaning.

Indeed, as I read John's rebuttal (?) to my follow-up to Keith's message,
I understood him to be saying exactly that same thing.  However, I also
perceived that he was intending to disagree with that statement.  So,
like Glenn, I am still confused.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: "John C. Strassner" <[email-masked]>
Date: Sun, 30 Jan 2000 12:59:42 -0800

Hi Bob,

the last email I sent to Glenn assumes that the "ALL" part of the 
definition, as initially defined by Shai and Keith, applies to the 
selection process as well. In other words, "Ethernet+Overflow" doesn't just 
select all Ethernet policies and all overflow policies, it selects the 
subset that apply to Ethernet and overflow.

What it appears that you and Glenn are saying is that you want room to 
interpret how the different roles in a role-combination are used to create 
the selector.

I'm fine with broadening this, but would really like to hear back from 
Keith, Michael Fine, and Shai before we set this in stone.

regards,
John

---

From: "John C. Strassner" <[email-masked]>
Date: Sun, 30 Jan 2000 12:54:47 -0800

Hi Glenn,

comment inline.

regards,
John

At 10:27 AM 1/30/00 -0500, Glenn Waters wrote:

>[gww] I m still confused. The way I read the Policy CIM is that a role is 
>associated with a policy. In one of your examples above you say &if it 
>makes sense for both of these (and other) Overflow policies to be 
>associated with "Ethernet+Overflow", that's fine& which to me implies that 
>a policy is associated with a role combination. I can t figure out which 
>is intended.

[js2] In the PFCIM, we allow for either a role or a role-combination to 
serve as the selector for identifying one or more policies that are 
applicable. So in the example below, it is equally correct for a single 
role as well as a role-combination to select a policy. The example below 
was unfortunate in that it only contained role-combinations. Does that help?

>(or multiple roles). When the policies for a particular role combination 
>are required then you pick each of the policies that match each of the 
>roles in the role combination.  So for example, the role combination 
>Ethernet+Overflow would select the Ethernet policies and the Overflow policies.

[js2] This is why I prefer thinking of roles as selectors, not just 
attributes. The intent is to use the combination of roles in a 
role-combination to select which policies apply. So to continue your 
example, "Ethernet+Overflow" would end up selecting all policies that are 
applicable for Ethernet AND affect "overflow".

---

From: Bob Natale <[email-masked]>
Date: Mon, 31 Jan 2000 14:19:09 -0500

At 1/30/2000:03:59 PM, John C. Strassner wrote:

Hi John,

Thanks for your patience on this...I do feel that we're making progress.

>the last email I sent to Glenn assumes that the "ALL" part of the definition,
>as initially defined by Shai and Keith, applies to the selection process as well.
>In other words, "Ethernet+Overflow" doesn't just select all Ethernet policies and
>all overflow policies, it selects the subset that apply to Ethernet and overflow.

Yes, that would be my understanding too...and further serves to bolster
the original (and only) point I am trying to make on this thread, to wit:

>What it appears that you and Glenn are saying is that you want room to interpret
>how the different roles in a role-combination are used to create the selector.

I can't speak for Glenn, of course...but the only thing I am trying to clarify --
which your explanation above supports -- is that a "role-combination" does *not*
necessarily refer to the set of *all* roles supported by a "network entity/component"
...rather, it only refers to the subset defined by the combination ("Ethernet+Overflow",
in the example above...not "all Ethernet and  all Overflow roles in the network entity/
component"...much less "all roles in the network entity/component").  So, we seem
to be saying the same thing here.

>I'm fine with broadening this, but would really like to hear back from Keith,
>Michael Fine, and Shai before we set this in stone.

Sounds fair to me...thanks.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------