Subject: Re: Policy issues: definition of Roles

From: [email-masked]
Date: Fri, 28 Jan 2000 03:23:50 -0500

Jon,

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

We have tried to be consistent in the application of an important principle:

Policies are relatively static, compared to changes in state in the network.
That is, we expect policies to change on a human time scale, and that they
will typically changed by human beings, rather than procedural execution of
code or scripts.  This has fewer limitations than you might, at first, think,
and it saves alot of headaches in conflict resolution.

To quote from your later reply to Walter:

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

I think you can deal with this in a structured way using the current model,
and using the structure has significant benefits.  To deal with the case where
a network failure affects a qos policy, one approach is to apply policy priority
in the model.  That is, if you match on a failure mode condition in the network,
you can kick in backup policies by making them a higher priority than the normal
policy rules for qos.  If you don't already have these higher priority rules
pre-defined, then I would say you need to involve a human to define them in any
case, in order for the network administrator to know what to expect when the
failure mode is present, and the backup policies are activated.

Policies modifying policies sounds like a recipe for an indeterminant result,
to me, at least until we get more experience with mass configuration of network
devices controlled by policies.  Please see my posting on procedural vs.
declarative.
We may want to tackle this rich problem space in the future, but I think this is
a case where caution and simplicity are the better part of valor ("walk before
run"
concept).

Ed

---

From: Jon Saperia <[email-masked]>
Date: Fri, 28 Jan 2000 07:30:30 -0500

> a case where caution and simplicity are the better part of valor ("walk before
Ed, I will use this to consolidate all responses to a couple of
messages. First with regard to the definition of Role. There seems to be
consensus that a role is an attribute. People know what an attribute is,
say interface speed, or ability to do WFQ, etc. Given this adding
another term, role, does not add anything in my view. If we mean
attribute say that.  A role is a combination of attributes (what some
people already call role combination). I really do not worry too much
about this, it just seems like an extra level of indirection.

With regard to nested policies. I was not suggesting policies
dynamically changing others. In a sense they are pre-defined. Can you
tell me how we would accomplish what you suggest in the first paragraph
above. That is how the failure condition would be expressed and related
to the other policies?

Thanks
/jon

---

From: Bob Natale <[email-masked]>
Date: Fri, 28 Jan 2000 08:26:57 -0500

At 1/28/2000:07:30 AM, Jon Saperia wrote:

Hi Jon,

>about this, it just seems like an extra level of indirection.

Hmmm.  Yes, it is a level of indirection...bet one designed to serve
a purpose...a "Role" is an abstranction that serves to map one or
more physical or logical attributes of (rarely) one or (typically)
more network entities into a generic policy behavior.

At least that's how I see it as one who is reading (in catch-up
mode!) and considering this stuff from the perspective of one who
would like to put these concepts to work in the future w/o trying
necessarily to be one who plays a big role in defining it all...so,
I hope it's clear that I am just trying to contribute to consensus
idenfication and not trying to change any course that's already been
agreed to...thanks.

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: Keith McCloghrie <[email-masked]>
Date: Fri, 28 Jan 2000 17:07:46 -0800 (PST)

>                                                 ...  There seems to be
> another term, role, does not add anything in my view. 

But, it's a particular type of attribute: one that denotes a
characteristic or function.  There are other types of attributes which
are not roles (e.g., ifInOctets).

Keith.

---

From: Jon Saperia <[email-masked]>
Date: Sat, 29 Jan 2000 09:42:35 -0500

> are not roles (e.g., ifInOctets).

Keith, your short sentence is the best I have seen so far. If the blank
could be filled in with a word or just a few, that would help things a
lot from my perspective.

A role is a type of attribute that dentoes a __________ characteristic
or function.

/jon

---

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

OK, how about this:

    A role is a type of attribute that is used to select
    one or more policies for a set of entities and/or
    components from among a much larger set of
    available policies.

This definition keeps the "attribute" association that people like, but 
emphasizes the logical function of roles as that of a selector.

regards,
John

---

From: Bob Natale <[email-masked]>
Date: Sun, 30 Jan 2000 12:04:31 -0500

At 1/30/2000:12:55 AM, John C. Strassner wrote:

Hi John,

>    components from among a much larger set of

Works for me.

Given that, how then would you define "role combination"?

For my part, I just can't see any reason to go beyond
"A role combination is a set of roles." ...which, it
could be argued, does not convey a lot added value.

>This definition keeps the "attribute" association that
>people like, but emphasizes the logical function of roles
>as that of a selector.

Right.

Cordially,

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

---

From: "John C. Strassner" <[email-masked]>
Date: Sun, 30 Jan 2000 13:04:08 -0800

Hi Bob,...

> >    components from among a much larger set of

[js] Great!

>Given that, how then would you define "role combination"?

[js] A role-combination is a set of attribute that are used
      to select one or more policies for a set of entities
      and/or components from among a much larger set of
      available policies. The selection process is equivalent
      to a logical ANDing of each attribute, such that the
      set of policies that are selected are defined by the
      intersection of all roles in the role-combination.

Note that you and Glenn are questioning the use of the logical AND as the 
selection process, and that in a previous message I've said that I'm ok in 
defining other types of selection processes, but want to hear from Keith, 
Michael and Shai (at least) first. If we did want to do that, then we 
probably need at least an associated attribute that defines how the 
selection process for the role combination is done.