Subject: RE: Policy issues: definition of Roles

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 28 Jan 2000 17:00:24 -0500

Ed,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 28, 2000 1:13 AM
> To: Weiss, Walter
> Cc: [email-masked]
> Subject: Re: Policy issues: definition of Roles
> 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.
> 
While 1 is the definition I would prefer, some (including myself) are a bit
confused with the current text.

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

<PCIM>
Figure 4 illustrates how roles and two concepts closely related to
roles, the policy subject and the policy target, operate within the
Policy Framework.  Because the distinction between them is not
important to this discussion, the PDP and the PEP are combined in one
box.  The points illustrated here apply equally well, though, to an
environment where the PDP and the PEP are implemented separately.
</PCIM>

I had trouble drawing anything useful from this text. If this text somehow
refers to text in the policy framework, perhaps a reference would help.

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

> 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 disagree. If all policies carry is attribute names and a role for the
policy, it is impossible for a PDP to interpret the policy unambiguously.
Please consider the numerous examples of policies I have given in this
thread that would be ambiguous without attribute level qualifiers.
> 
> 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?
> 
Refer to comments above on current text issues.

---

From: "Jon Sjoberg" <[email-masked]>
Date: Sun, 30 Jan 2000 06:08:28 -0800

Walter,

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

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