Subject: RE: Policy issues: definition of Roles

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 11 Feb 2000 15:48:05 -0500

John,

I would agree that this is somewhat unrelated to the concept of roles,
assuming that roles focus on distribution issues. However, at some point we
will have to agree on how we can achieve the unambiguous interpretation of
the policy conditions and actions.

regards,

-Walter

> -----Original Message-----
> From: John C. Strassner [mailto:[email-masked]]
> Sent: Sunday, February 06, 2000 8:37 PM
> To: Weiss, Walter; 'Jon Sjoberg'
> Cc: [email-masked]
> Subject: RE: Policy issues: definition of Roles
> 
> 
> <walter wrote:>
> 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.
> </walter>
> 
> I would humbly submit that this issue, though important, is 
> orthogonal to 
> roles. See my earlier posting. This is a binding issue, and 
> affects not 
> just roles (which are, after all, attributes) but other types 
> of attributes 
> as well.
> 
> regards,
> John
> 
> At 01:36 PM 1/31/00 -0500, Weiss, Walter wrote:
> >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
> >
> > > -----Original Message-----
> > > From: Jon Sjoberg [mailto:[email-masked]]
> > > Sent: Sunday, January 30, 2000 9:08 AM
> > > To: Weiss, Walter
> > > Cc: [email-masked]
> > > Subject: RE: Policy issues: definition of Roles
> > >
> > >
> > > 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: "Yoram Snir" <[email-masked]>
Date: Sun, 13 Feb 2000 15:45:48 +0200

Walter
Wouldn't distribution issues and unambiguous interpretations of policy rules
(conditions and actions) are 2 different issues?
The methods used to solve the first issue, Roles for example, is not the
method to solve consistent decision making (clear priorities, decision
strategy...).
Thanks.

Yoram Snir
Cisco Systems
Tel.   972-9-9700085
Mobile 972-54-970085

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Weiss, Walter
> Sent: Friday, February 11, 2000 10:48 PM
> To: 'John C. Strassner'