Subject: Re: PCIM Extensions

From: Mahadevan Iyer <[email-masked]>
Date: Tue, 16 Jan 2001 01:43:38 -0800 (PST)

Lee,

> 
> I think the requirement is now understood, it's just
> the solution that needs
> further discussion.
OK

> 
> >   2. There are 3 types of policy domains which
> need to
> > be supported in the application viz.
> Administrative,
> > Functional and Enforcement. Organizing the
> containment
> > according to one of these domains does not solve
> the
> > problem of the remaining two domains. The three
> > domains could be completely overlapping or
> mutually
> > exclusive.
> >      There needs to be an uniform means to map all
> > three domains.
> 
> Say more.

Administrative domain - decides who gets to modify
which parts of the policy database

Functional domain - indicates the functionality being
addressed by the policies e.g. Firewall, QoS etc.

Enforcement domain - decides the physical or logical
region over which the policy is to be enforced.

The "Functional Domain" is less important than the
others, but neverthless required. I see the PolicyRole
providing this capability but more on that later ...

In a lot of instances the Administrative domain and
Enforcement domain go hand in hand. e.g."EastCoast"
admins will manage policies for "EastCoast" domains.
But when the administrative domain does not map to the
enforcement domain there is a need to separate them.
e.g. A single "EastCoast" user administrator manages
user groups for the "EastCoast" as well as "WestCoast"

> 
> >   3. There needs to be a means to formally specify
> the
> > policy target(some overlap with the enforcement
> > domain) in the policyrule. I am looking for
> something
> > that is stronger than a policy condition variable
> > type. The logic that led to the creation of
> > "PolicyTimePeriodCondition", instead of adding a
> > policy condition variable type, could be applied
> out
> > here.
> 
> What are the functions you're looking for that are
> not provided by
> PolicyRole?

The PolicyRole from [PCIM]
=======================
Using the roles and role-combinations it received from
its PEPs as
      indicated in the examples above, the PDP is able
to locate and
      retrieve the policy rules that are relevant to
it.
========================

This is used to indicate a class of consumers e.g "all
policy enforcers that implement a firewall" should
pick up policies that have "firewall" mentioned in
their "PolicyRole" attribute.

This does not address the problem of which of the 10
firewalls in the network need to download the policy.

This is how I read it, maybe you could tell me how the
PolicyRole is supposed to be used.

Thanks

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 16 Jan 2001 09:41:52 -0500

Mahadevan,

Thanks for the additional explanations.  A few thoughts in reply....

> user groups for the "EastCoast" as well as "WestCoast"

In your example, isn't it simply that there are a set of administrators that
have rights for administering both the east and west domains?  I think one
has to ask why resources are divided into domains.  I suppose there can be
scaling issues but the way I've thought of administrative domains is that
policies within a domain are consistent and coherent.  That is, the
enforcement points within a domain are all cooperating to achieve some
consistent set of organizational objectives.  If it's scaling issues that
cause one to break a logical domain into subdomains then I'd try to
represent them that way, if for no other reason than to capture the common
organizational objectives.

                    AdminDomain
                        USA
                      /     \
                     /       \
                    /         \
            AdminDomain     AdminDomain
                West           East

The users that are authorized to administer the resources within a domain
can be associated with the superior and/or subordinate domains as needed or
with multiple disjoint domains for that matter.

Am I missing something?

> The PolicyRole from [PCIM]

We've found PolicyRole to be a bit problematic as well.  It's overloaded and
I don't think it has a clear delineation from conditions.  The terminology
doc says it's "an administratively specified characteristic of a managed
element...to determine the applicability of the rule/PRC to a particular
managed element."  We're not confined to a single functional PolicyRole
(e.g., "firewall"), one can have role combinations for "firewall&&interior"
or "exterior&&firewall" thus defining the sets of policy consumers by both
function and an interface classifying qualifier.  Similarly, one can have a
function and qualifiers like "firewall&&interior&&raleigh.ibm.com" adding
another characteristic for network domain thus fully specifying an example
of what you've called the functional and the enforcement domains.

Does that help or is there more needed?

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: Yoram Ramberg <[email-masked]>
Date: Thu, 18 Jan 2001 14:01:19 +0200

[...snip...]
>The PolicyRole from [PCIM]
[...snip...]

Ah... Actually, my reading of this is slightly different. However, I have 
my problems with that text, which may be also the cause for the apparent 
misunderstanding. The following text from PCIM seems to imply what you said:

   "A role represents a functional characteristic or capability of a
    resource to which policies are applied.  Examples of roles include
    Backbone interface, Frame Relay interface, BGP-capable router, web
    server, firewall, etc. "

However, this is quite restrictive and unnecessary. Furthermore, it is not 
(IMO) the intention of the authors at all!.
I think of a role as a mapping mechanism between policies and their 
targets. The above text represent an example where roles are used to map 
policy to objects that have some "functional characteristics" such as 
"Backbone interface", etc. However, these are just names, nothing more. 
"Frame Relay" may be a role name and the mapping of a given policy using 
this role *may be* interpreted by a (a very smart) PDP to frame relay 
interfaces. Another usage for role will be "VPN1-Ingress". This is, yet 
again, a name. How to assign this name to actual network elements is way 
outside the scope of PCIM. Within a given network, the 'VPN1-Ingress' role 
may be assigned to a bunch of interfaces determined to be serving in this 
role. Some of those may be actually frame relay while others may be ATM and 
maybe even virtual tunnel interfaces or what have you. No requirement is 
placed on a semantic mapping from the value of the role name to a member in 
a set of network elements carrying this role.
This means that the mapping you desire is exactly what roles do. This also 
means that the text you're referring to in PCIM is somewhat misleading.

Bottom line: The role *may* represent a functional characteristic. It may 
also represent more or less than a functional characteristic, say a 
functional characteristic and an administrative purpose.

One more thing about this example: The text also says that the roles are 
received from the PEPs. This is true only when the PEPs and PDPs use COPS 
to inter-communicate. Notwithstanding the PEP/PDP terminology, this is not 
only the case. Indeed, this is still the minority case in the real world to 
date. I'm just saying this lest further confusion is created by that text.

*Yoram