Subject: Re: Policy issues: definition of Roles

From: Bob Natale <[email-masked]>
Date: Tue, 25 Jan 2000 14:55:08 -0500

At 1/25/2000:02:08 PM, Weiss, Walter wrote:

Hi Walter,

><...>
>1. A role is a list of targets for a policy to be applied to. In other
>words, if the policy conditions and actions describe some interaction with
>or within an interface, the role lists the interfaces that the policy is
>applicable to. If the policy describes some OSPF related rules, then the
>role is the list of OSPF instances. This definition is more applicable to
>how policies are distributed
>
>2. A role describes the binding between the set of attributes used in a
>policy and the actual attributes that exist in a device or service. For
>example, a policy that prevents new flows when total bandwidth for that flow
>type exceeds 30% of all traffic, may need an explicit binding of the
>bandwidth counter attribute and the flow type definition to a particular
>instance of a queue. This definition speaks more to how a policy is
>interpreted.
>
>My take is that these two definitions are nearly the same. However, if a
>role is assumed to be associated with the rule, I would be inclined to favor
>definition 1.
><...>
>Comments?

I don't see much need for interpretation #2.  I favor the association
of roles with rules and, therefore, I favor definition #1.  I really
don't have much to add to your rationale, but would like to see consensus
quickly form around the Def #1 use of "role" and see us move on to
resolution of additonal issues.  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: "Weiss, Walter" <[email-masked]>
Date: Wed, 26 Jan 2000 12:31:25 -0500

Jon (Sjoberg),

I believe that PFCIM currently uses definition 1. "Resources" in this
context appear to me to be the equivalent of PIB/MIB rows and or classes in
an information model. However, I would defer to the authors for their
interpretation. If it is indeed definition 1 they were considering, we may
need to rethink it. As I suggested previously, this approach while sound for
COPS/SNMP places potentially sever restrictions on the types of policies
that can be constructed.

regards,

-Walter

> -----Original Message-----
> From: Jon Sjoberg [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 11:22 AM
> To: Weiss, Walter; [email-masked]
> Subject: RE: Policy issues: definition of Roles
> 
> 
> So the term "role" which you wished to get clarified is 
> separate from the
> term "role" defined in the PFCIM document, correct?
> 
> If these terms are different we should probably get the terms 
> altered a bit
> to remove yet a third point of confusion from your list.
> 
> If these terms are the same would you mind holding my hand a 
> little to show
> me how they are the same?
> 
> Thanks,
> Jon
> 
> > -----Original Message-----
> > From: Weiss, Walter [mailto:[email-masked]]
> > Sent: Wednesday, January 26, 2000 11:08 AM
> > To: 'Jon Sjoberg'; [email-masked]
> > Subject: RE: Policy issues: definition of Roles
> >
> >
> > Jon,
> >
> > To answer your question, Roles were first proposed in the 
> context of PIBS.
> > In this context, a PIB row, or subset thereof, was 
> associated with a group
> > of one or more services/components. In this context definition 2 is
> > perfectly reasonable because a PIB row is always unambiguous,
> > even if it is
> > applied to a set of instances. In policy, this concept (and 
> definition 2)
> > was inherited. However, attributes that will not be part of the
> > same PIB row
> > will often coexist in the same policy. As I said in my 
> first message, I
> > noticed this confusion during discussions with other folks at the
> > last IETF.
> >
> > regards,
> >
> > -Walter
> >
> > > -----Original Message-----
> > > From: Jon Sjoberg [mailto:[email-masked]]
> > > Sent: Tuesday, January 25, 2000 8:46 PM
> > > To: [email-masked]
> > > Subject: RE: Policy issues: definition of Roles
> > >
> > >
> > > Not to seem too ignorant, but where did these definitions
> > > come from?  There
> > > is a definition of roles in "Policy Framework Core
> > > Information Model --
> > > Version 1 Specification", section 5.2, which I can't quite
> > > match to either
> > > of the E-mailed definitions.
> > >
> > > In this draft a role is defined as:
> > > "a policy administrator assigns each resource to one or more
> > > roles, and then
> > > specifies the policies for each of these roles."
> > >
> > > Then, further on, this draft states:
> > > "Roles are represented in the Core Policy Schema by values of
> > > the Policy
> > > Keywords property."
> > >
> > > Of which, section 6.1.2 further enumerates to be:
> > > "This document defines the following keywords:  "UNKNOWN",
> > > "CONFIGURATION",
> > > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", 
> "INSTALLATION", and
> > > "EVENT"."
> > >
> > > The best I can see is if we take definition number 1, and
> > > generalize it out
> > > several orders, we sorta match the PFCIM definition.  Any
> > > insight to help
> > > me?
> > >
> > > Thanks,
> > > Jon
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Weiss, Walter
> > > Sent: Tuesday, January 25, 2000 11:08 AM
> > > To: [email-masked]
> > > Subject: Policy issues: definition of Roles
> > >
> > >
> > > At the last IETF, numerous conversations resulted in a number
> > > of new issues
> > > that deserve discussion and consensus. I would like to start
> > > addressing
> > > these issues from easiest to hardest with a desire to have
> > > them all resolved
> > > prior to the next meeting. My intent is to serialize these
> > > discussions to
> > > give each topic a fair hearing. However, if we run out of
> > > time, I will start
> > > initiating parallel threads.
> > >
> > > The first issue is one I eluded to in my presentation. There
> > > are apparently
> > > two definitions for Role:
> > >
> > > definition 1. The reason is that I anticipate the possibility
> > > of policy
> > > rules that either interact with multiple instances of the
> > > same time (If Gold
> > > Traffic exceeds a threshold, lower bandwidth allocation for
> > > Silver Service)
> > > or transcend service domains (When a new DHCP accounting user
> > > is validated
> > > install a packet filter granting access to the accounting
> > > network). In the
> > > first example a role listing the queues/services to which
> > > this policy is
> > > applicable is reasonable. However, a role binding of the rule to a
> > > particular set of queues/services is ambiguous because the
> > > gold service
> > > queue and the silver service queue would each interpret the
> > > rule as "If MY
> > > traffic exceeds this threshold reduce MY bandwidth." What we
> > > really want is
> > > "If MY  traffic exceeds this threshold reduce the OTHER
> > > bandwidth." In the
> > > second example, according to definition 1 of role, the policy
> > > server would
> > > determine that the role is applicable to the DHCP service and
> > > the filters on
> > > edge interfaces of the accounting network. Under definition
> > > 2, the attribute
> > > binding is confusing because the DHCP service has no 
> packet forwarding
> > > service and the routers don't (usually) have a DHCP service.
> > > Therefore a
> > > subset of the attributes are ambiguous. The only way to
> > > disambiguate this
> > > type of rule is to qualify the attribute:
> > > DHCPService.NewUserAddress and
> > > AccountingEdgeInterfaces.SrcAddrFilter. With this level 
> of attribute
> > > qualification, the value of roles under definition 2 seems almost
> > > irrelevant.
> > >
> > > Comments?
> > >
> > > regards,
> > >
> > > -Walter
> > >
> > >
> > >
> >
>

---

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Thu, 27 Jan 2000 10:35:12 -0500

Hi Walter,

I think definition #1 is the better of the two with respect
to the concept of roles as introduced in the PIB (though I'm
not sure a list of interfaces is the best example of a role,
you can certainly do it that way). 

I don't fully understand definition #2 and so I'm having
trouble seeing how you are describing that definition in 
the context of PIB. Just looking at the definition, what is 
the "role" in the example (preventing new flows) you gave? 
This would help with understanding, I think.

Thanks,
-Fran

> In this context, a PIB row, or subset thereof, was associated 
> with a group
> was inherited. However, attributes that will not be part of 
> the same PIB row
> will often coexist in the same policy. As I said in my first 
> message, I
> noticed this confusion during discussions with other folks at 
> the last IETF.
> 
> regards,
> 
> -Walter
> 
> > "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL", "INSTALLATION", and
> > "EVENT"."
> > 
> > binding is confusing because the DHCP service has no packet 
> forwarding
> > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute

---

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 27 Jan 2000 17:39:46 -0500

Jon,

The notion of policy hierarchies bleeds a bit into the other thread I posted
yesterday. In the context of declarative policies (as I defined them), there
was some debate during the meetings over whether policy nesting or even
ordering should be allowed due to the additional complexity (particularly in
conflict detection).

I would also point out that you have sliced the problem a little differently
from the way I sliced it in my original message. I suggested that it is
possible to have a single policy that crossed resource/technology/client
type boundaries. You on the other hand suggested that a policy be restricted
to within a single resource but that another policy could bind two resource
specific policies together. These two alternative approaches are also well
worth discussing (if you want). However, I would suggest a separate thread
because I would like to close on the terminology in this one.

regards,

-Walter

> From: Jon Saperia [mailto:[email-masked]]
> Sent: Thursday, January 27, 2000 6:22 AM
> To: Weiss, Walter
> Cc: [email-masked]
> Subject: Re: Policy issues: definition of Roles
> 
> 
> "Weiss, Walter" wrote:
> > 
> > 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?
> > 
> 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: "Weiss, Walter" <[email-masked]>
Date: Thu, 27 Jan 2000 17:03:02 -0500

Fran,

I believe poor definitions for terms is exactly why we are having so much
trouble making progress. Hence, I applaud the work you folks are doing in
the terminology draft. So let's try to work on the question you posed.

In many of the discussions I have been in (and presentations I have seen), I
have seen roles used for two distinct objectives. In one case a role is used
as a means for determining the policy targets (i.e., the set of components
or services that the policy will either be influenced by or influence). In
the more explicit interpretation of role, there has been a desire to provide
a binding between the attributes expressed in the policy and the actual
attributes in the component or service interacting with (influenced or being
influenced by) policies. Now, in PIBs and MIBs the binding between the
attribute values in the message and the actual attributes in the device is
implicit because the attributes are grouped together is such a way that all
the attributes are easily bound. Let's consider a hypothetical case where we
constructed a MIB or PIB that contained the two dropping thresholds for two
different queues without specifying the queue. In this case, there would be
no way to determine which threshold was for which queue. However, we don't
do this in MIBs or PIBs. In practice, we create separate row for each
specific queue with a set of attributes for that queue. This way, we specify
the queue number is specified once in the message and we know that all
remaining attributes are for the queue. The identification of the queue we
are interested in is just like definition 2 of a role in that it binds a set
of values to a specific instance of a queue.

In policy, as I have pointed out earlier, it is quite common for policy to
be too broadly defined so that a binding to specific attributes at the
policy level is insufficient for the proper interpretation of the policy. A
simple example:

Set Queue2's drop threshold to Queue1's drop threshold.

	If you said that the role for the policy was Queue1 and Queue2, you
still don't know which instance of a threshold to assign to which other
threshold. You need a more explicit binding in the policy itself
(Queue1.DropThreshold = Queue2.DropThreshold). The concept of a role is
still valuable because you can provide a larger context for the policy such
as "for this set of interfaces on this set of switches."

This is why I would like to prevent the definition of role from implying
attribute level bindings in policies (Hence my opposition to definition 2).
Hope I am becoming clearer.

regards,

-Walter

> From: Francis Reichmeyer -NJ [mailto:[email-masked]]
> Sent: Thursday, January 27, 2000 10:35 AM
> To: 'Weiss, Walter'; 'Jon Sjoberg'; [email-masked]

---

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Thu, 27 Jan 2000 10:35:12 -0500

Hi Walter,

Thanks,
-Fran

---

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Thu, 27 Jan 2000 23:25:35 -0500

Walter,

> Sent: Thursday, January 27, 2000 5:03 PM
> To: 'Francis Reichmeyer -NJ'; [email-masked]

I'd say the trouble lies more in 'overloaded' definitions, rather 
than 'poor' ones, but I agree (just different terminology ;^) Also, 
discussions and threads like this should go a long way towrards helping 
to close the gap between some different conceptions.

> as "for this set of interfaces on this set of switches."

Right, agreed. The role for a policy like the one in your example
should not be "Queue1 and Queue2". However, the role could be
"all interfaces that support Queue1 and Queue2", which I think is
basically what you are saying.

Thanks,
-Fran

---

From: [email-masked]
Date: Fri, 28 Jan 2000 02:30:09 -0500

Walter,

(Sorry about taking several days to reply.  We had a small problem here with a
once-in-a-hundred-years snow accumulation, which caused some communications
problems.)

In your note of Jan. 25, you wrote, in part:

>....There are apparently two definitions for Role:
>....

In response:

The first definition, if I understand it's intent, is the one I think we had in
mind for the PCIM document. It seems to me that you are arguing in favor of
keeping that definition, and I agree with that. I also think that the words we
have in the PCIM document already capture the essence of that definition:

   A role represents a capability that operates at the
   point where a policy is applied.  Examples of roles
   include Frame Relay interface, BGP-capable router,
   web server, and firewall.

The policy we store in the policy repository has always, from the very start of
the policy framework working group, been intended to be  device-independent.
Therefore, the policy we put into the policy repository cannot be constrained by
a role concept that is device-specific, as it is in definition #2.

Definition #2 defines device-specific configuration. Of course, the config needs
to carry out the policy, so the two have to be mapped, which is where the PDP
function comes in. I agree with Shai's comment on this, in his note dated Jan.
27.

You are right to point out the misunderstanding between the two groups of
authors.  Do you have a suggestion regarding a way to differentiate the two
concepts?  Perhaps, PCIM could use the term "functional role", and the PIB
authors could use a term like "configuration role"?  Ideas?

Ed Ellesson
Tivoli Systems
Research Triangle Park, NC
[email-masked]
919-254-4115

---

From: [email-masked]
Date: Fri, 28 Jan 2000 01:13:15 -0500

Walter,

In response:

Ed Ellesson
Tivoli Systems

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 28 Jan 2000 16:32:44 -0500

Ed,

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

I think you are mixing up concepts again. You are confusing simplicity and
the static nature of policies with possible approaches for defining
policies. CLI is a prime example of a script that is both simple and static.
The only thing it is not is box independent.

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 28 Jan 2000 16:32:42 -0500

Shai,

> 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?
> 
I see little distinction between roles and attributes in your definition. If
this is the definition we would agree to, I would suggest that we remove the
concept of roles altogether.

The main reason why concept was introduced was to address logical attributes
in policies to actual attributes in a set of devices. The question is at
what level of detail is this binding specified. If it is at the attribute
level, then the binding would need to be in the policy itself (as opposed to
being associated with the policy). If a policy describes an interaction
between two queues or two interfaces or two services located on the same
device, you need some type of explicit qualification to distinguish the two
in the policy. The concept of being able to distinguish components within a
device is distinct from the concept of which devices or components the
policy is applicable to.

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 28 Jan 2000 16:32:43 -0500

Fran,

> basically what you are saying.
Exactly. Thanks.

-Walter

---

From: "Ken Roberts" <[email-masked]>
Date: Fri, 28 Jan 2000 15:39:05 -0500

Group,
Roles should be straight forward. IMO they define cardinality in a
relationship, when management is involved we need an invoker and a performer
of any given operation this specification is done using Roles, that is an
entity either is a invoker or performer for a given instance of an operation
(or notification).
Obviously this isn't something that can be statically defined and over time
may move within an intelligent network, more probably it is something that
will/ should be negotiated between two entities on a as needed basis.
I realize the above introduces concepts and terms we haven't debated and for
this I apologize but I don't think anything is served if we begin redefining
terms that have a well known meaning in relationship modeling. That will
only further confuse folks.

--------------------------------------------------------------------------
Regards,
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   :        655-7844			?Direct  : 408-565-7844
?  Fax    :        408-565-8226
? email :      [email-masked]
 
This message may contain information proprietary to Nortel Networks
Corporation so any
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited.

 -----Original Message-----
From: 	Francis Reichmeyer -NJ [mailto:[email-masked]] 
Sent:	Friday, January 28, 2000 9:57 AM
To:	'Jon Sjoberg'; Shai Herzog - NJ; Jon Saperia; Weiss, Walter
Cc:	[email-masked]
Subject:	RE: Policy issues: definition of Roles

Hi Jon,

> 
> I like Shai's definition, with one minor tweak:
> 
> 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.

With regards to your tweak:
By "high level role" do you mean a role that represents what you are
calling a high level element or are you implying there are different
types of roles: low level and high level, plus role combinations?

Thanks,
-Fran

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 28 Jan 2000 16:32:43 -0500

Fran,

Exactly. Thanks.

-Walter

---

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 31 Jan 00 10:18:12 CET

Mmmm.... this discussion seems to belong in the Policy Terminology
mailing list. But clearly, now that we have a WG Last Call outstanding,
now we need to nail down the definitions. So it is good to have
the discussion.
I see we're starting to converge, but I do not see full agreement yet.
We may want to try and get agreement in this WG real quick, and then
try to sense out if other people agree on the polterm mailing list.

Bert

---

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 31 Jan 2000 13:36:24 -0500

Jon,

Since my posting, the intent of Roles (in the form of keywords and keyword
combinations) has become clearer to me. With role combinations, I can create
policies that cross domains. That said, I wanted to draw attention to the
text because it was too vague for me to understand what the intent was.

It seems that the definition of Roles that PCIM authors had in mind is a bit
more high level then what I was thinking of. I don't have any problem with
grouping policies together based on some keyword. These are fairly abstract
concepts that I could easily see  as useful for policy conflicts. However, I
have not seen the rubber hit the road yet.

In the original posting, my main concern was that the policy rules, and more
precisely the attributes within policy rules, eventually have to be bound to
some physical attribute somewhere in order to effect changes in network
devices or services. Specifying keywords is not enough. We should also
document how an attribute actually maps to given instances of that attribute
in an interface, queue or whatever. We could use the role keyword as a way
of indicating which set of interfaces or queues we would like the policy to
apply to, but then we need a mechanism to bind the keyword to that set. If
that is the approach taken, then we still have attribute qualifiers to deal
with, but at least I know how I can use Role Keys beyond conflict detection.

As a side note, we are spending a considerable amount of time focused on
device interfaces. I would like to remind folks that the purpose of this
working group is to come up with a framework that can not only be applied to
QoS components in forwarding engines, but also other problem domains.
Security policies, Address management policies, and Routing policies have
little if anything to do with interfaces. While I am comfortable with
focusing on QoS (as per our charter), I would like to make sure that we
don't make assumptions about how and where policy will be used.

regards,

-Walter

> Sent: Sunday, January 30, 2000 9:08 AM
> To: Weiss, Walter
> > <PCIM>
> > The Policy Framework is then responsible for configuring
> > each of the resources associated with a role in such a way that it
> > behaves according to the policies specified for that role.
> > </PCIM>
> >
> > First, there is a reference to resources without any context.
> > Second, I find
> > policies that can only operate within the confines of a
> > particular resource
> > unnecessarily restrictive.
> >
> I don't understand where the second point is derived from.  I 
> guess I read
> the text to say that policies are confined within a specific 
> role.  It seems
> that policies, in the general sense, can operate across 
> resource and role
> boundaries.  Each policy rule that enacts a policy must be restricted,
> however, to a role.  It would be easier, from a PDP/PEP 
> implementation stand
> point, to restrict each policy rule down to a resource (and 
> make the policy
> management tool do all the REAL work).
> 
> >
> > <PCIM>
> > Roles are represented in the Core Policy Schema by values of the
> > PolicyKeywords property.
> > </PCIM>
> >
> > I found this text to be even more confusing because it 
> supported a third
> > concept not defined in either of the two concepts I described: an
> > arbitrary
> > grouping based on a keyword possibly bound to a technology 
> like QoS or
> > security, or an organization like engineering, or something else???
> >
> Actually the possible current values are enumerated in 6.1.2, 
> and the values
> fall into the "something else" category.  If I read 
> correctly, the standard
> possible values are:
> UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", 
> "MOTIVATIONAL",
> "INSTALLATION", and "EVENT".  I am not sure I fully understand many of
> these, though the document does explain them.  Anyway, it is 
> clearly another
> definition of role not akin to your two or, best I can tell, 
> Shai's newest
> proposal.
> 
> 
>

---

From: [email-masked]
Date: Mon, 31 Jan 2000 18:04:45 -0500

I am forwarding this, and a few other notes  to the mailing list on behalf of
John Strassner, since he is temporarily using a source mail address that is not
on the mailling list.

---

From: John Strassner <[email-masked]>
Date: Mon Jan 31 19:30:35 GMT 2000

Comments inline.

regards,
John

At 06:08 AM 1/30/00 -0800, Jon Sjoberg wrote:
Walter,

> First, there is a reference to resources without any context.

<jcs>
The intent is for the policy to use the role as one of several selectors to
define the context for configuring the resource. For example, consider a
financial institution defining policies that allocate resources based on
market conditions. Roles and policies enable it to respond much faster, and
in a predictable fashion, to changing market conditions than relying on
individually configuring these resources. This institution could have two
policies that configure the same network resources in different ways,
depending on the market conditions. The context is determined by roles as
well as other external conditions.

If you want, text such as this could be added to make the meaning clearer.
</jcs>

> unnecessarily restrictive.

<jcs>
Please refer back to the earlier response that I sent to Ken and Walter.
Roles are simply selectors, to choose a subset of applicable policies from
among a larger list. I don't think that the statement in the PFCIM that you
are quoting says or doesn't say this. In the general case, a policy may or
may not need to be restricted to a particular resources, and I find nothing
wrong with doing either.

On the other hand, if you are worried about the PFCIM not being able to
protect the policy designer from himself or herself, then keep worrying ;-)
I see no way that we can do this. If a policy designer wants to write a
restrictive policy, then that is his or her right. We shouldn't prevent
this, just as we shouldn't prevent the policy designer writing a very
general rule.
</jcs>

I don't understand where the second point is derived from.  I guess I read
the text to say that policies are confined within a specific role. It seems
that policies, in the general sense, can operate across resource and role
boundaries.  Each policy rule that enacts a policy must be restricted,
however, to a role. It would be easier, from a PDP/PEP implementation stand
point, to restrict each policy rule down to a resource (and make the policy
management tool do all the REAL work).

<jcs>
Policies can be written to affect a single resource or multiple resources.
Roles are used to select policies. Policy rules can use roles as one of the
means to identify particular policies. If the policy rule says:

  IF Interface == Edge-Interface, THEN ...

the role Edge-Interface is used to select all interfaces that are
classified as Edge interfaces, and the action in the THEN clause is applied
to all such interfaces. If the interface only one resource to be managed,
so be it. If it allows multiple resources to be managed, then that's fine
too.

Finally, note that there is no restriction of having a policy rule be
restricted to a single role. For example:

  IF Interface == Edge-Interface AND
     (Interface == ATM-Interface OR Interface == FR-Interface)...
</jcs>

> I found this text to be even more confusing because it supported a third
> grouping based on a keyword possibly bound to a technology like QoS or
Actually the possible current values are enumerated in 6.1.2, and the
values
fall into the "something else" category.  If I read correctly, the standard
possible values are:
UNKNOWN", "CONFIGURATION", "USAGE", "SECURITY", "SERVICE", "MOTIVATIONAL",
"INSTALLATION", and "EVENT".  I am not sure I fully understand many of
these, though the document does explain them. Anyway, it is clearly another
definition of role not akin to your two or, best I can tell, Shai's newest
proposal.

<jcs>
Actually, the values define the types of policies that are described in
page 7, plus a catch-all (unknown). Now, we could have defined additional
values like "Edge" and "Core", but decided that by excluding values like
this, no bias was given in the core info model to any particular domain.
This enables us to use the PFCIM for things like DHCP, where "Edge" and
"Core" are meaningless. What is really needed is implementation experience,
and so we wanted to keep the keywords as general as possible.
</jcs>

_________________________________________________________
fsmail - get your free web-based email at: www.fsmail.net

---

From: Andrew Smith <[email-masked]>
Date: Mon, 31 Jan 2000 15:35:48 -0800

And, in particular, you only need to tell the device about those roles that
are relevant to it - that is where the big savings are, I think. e.g.

1. Device A has roles W, X and Y. 
2. Device B has roles W, X and Z. 
3. A policy that references roles W and X should be downloaded to both
devices.
4. A policy that references roles W and Y should be downloaded only to
device A, not device B.

The role combination concept in the PIB was introduced specifically in order
to do this: you have to be able to list only those roles that are relevant
to the policy, not necessarily ALL roles on the device, in a role
combination.

(Apologies if I'm repeating stuff here).

Andrew

> From: Bob Natale [mailto:[email-masked]]
> Sent: Monday, January 31, 2000 3:27 PM
> To: Andrew Smith
...

> That works fine for me.  All I care about on this thread is that a
> "role combination" DOES NOT HAVE to include ALL of the roles supported
> by a network entity/component (although there MAY well be a role
> combination which does incorporate all roles supported by a network
> entity/component).

---

From: "Ken Roberts" <[email-masked]>
Date: Mon, 31 Jan 2000 18:42:07 -0600

Gents & others,
I'm a little confused by Andrew's statement of a policy that has multiple
roles. I understood a policy had rules. Rules may be crafted to include the
notion of roles but are they separate rules or sub classes of one rule?
When the statement "A policy that references roles W and X" is made does
this imply there is a matrix relationship that can be established from one
parent policy (/rule)? How is this managed? Why is this required? If
policies have hierarchical structure can this not be done with containment
or another relationship?
I think I had better re-read the thread as maybe I've missed something.

 -----Original Message-----
From: 	Andrew Smith [mailto:[email-masked]] 
Sent:	Monday, January 31, 2000 3:36 PM
To:	'Bob Natale'
Cc:	[email-masked]; [email-masked]'
Subject:	RE: Policy issues: definition of Roles

Andrew

...

---

From: Andrew Smith <[email-masked]>
Date: Mon, 31 Jan 2000 17:23:33 -0800

e.g. "HTTP traffic gets AF treatment on all Ethernet and FDDI interfaces" is
a policy rule that references two roles: "Ethernet interfaces" and "FDDI
interfaces". You wouldn't bother sending that rule to token-ring devices.

(I guess I'm really an assembler programmer so I don't understand these
"class" and "subclass" things you talk about).

Andrew

P.S. Maybe we should drop the "policy framework" list from this thread since
this appears to be purely a "device" thing. But I did think we were
attempting the (maybe thankless) task of unifying the terminology between
all the WGs.

-----Original Message-----
From: Ken Roberts [mailto:[email-masked]]
Sent: Monday, January 31, 2000 4:42 PM
To: Andrew Smith; 'Bob Natale'
Cc: [email-masked]; [email-masked]'
Subject: RE: Policy issues: definition of Roles

Gents & others, 
  
 -----Original Message----- 
From:   Andrew Smith [mailto:[email-masked]] 
Sent:   Monday, January 31, 2000 3:36 PM 
To:     'Bob Natale' 
Cc:     [email-masked]; [email-masked]' 
Subject:        RE: Policy issues: definition of Roles 

...