Subject: policy model Q, SARuleInPolicyGroup::GroupComponent

From: Michael Baer <[email-masked]>
Date: Thu, 11 Apr 2002 09:53:41 -0700

Hi,

In the policy model, 4.7.2 :

>4.7. The Aggregation Class SARuleInPolicyGroup 
>    
>   The class SARuleInPolicyGroup associates a SARule with the 
>   IPsecPolicyGroup that contains it.  The class definition for 
>   SARuleInPolicyGroup is as follows: 
> 
>   NAME         SARuleInPolicyGroup 
>   DESCRIPTION  Associates a SARule with the IPsecPolicyGroup that 
>                contains it. 
>   DERIVED FROM PolicySetComponent (see [PCIME]) 
>   ABSTRACT     FALSE 
>   PROPERTIES   Priority (from PolicySetComponent) 
>                GroupComponent [ref IPsecPolicyGroup [1..1]] 
>                PartComponent [ref SARule [0..n]] 
>                 
>   Note: an implementation can easily partition the set of SARules 
>   aggregated by a SARuleInPolicyGroup instance into one IKERule 
>   instances subset and into one IPsecRule instances subset based on the 
>   class type of the component instances (being either IKERule or 
>   IPsecRule instances). 
>    
>4.7.1. The Property Priority 
> 
>   For a description of this property, see [PCIME]. 
> 
>4.7.2. The Reference GroupComponent 
>    
>   The property GroupComponent is inherited from PolicyRuleInPolicyGroup 
>   and is overridden to refer to an IPsecPolicyGroup instance.  The 
>   [1..1] cardinality indicates that a SARule instance may be contained 
>   in one and only one IPsecPolicyGroup instance (i.e., SARules are not 
>   shared across IPsecPolicyGroups). 

The GroupComponent explicitly states that SARules are not sharable
between IPsecPolicyGroups. I couldn't think of any reason for this
restriction and it seems arbitrarily limiting. So, basically, I wanted
to know what are the reasons for choosing a 1..1 cardinality here (as
opposed to say, 0..n or 1..n)?

thanks,
Mike

-- 
Michael Baer
[email-masked]
NAI Labs

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 18 Apr 2002 18:38:22 -0400

Mike, If memory serves me well, it was just a simplification of the core
model.  The core model permits arbitrary reuse of conditions and actions in
rules, rules|groups in rules|groups, etc. and we add to that structure a
couple of associations that eventually get you to the interface(s) to which
the rules apply.  It's all quite workable if we have a need for the
generality, but the authors agreed early on to the simplifications and no
one challenged it.

If there's a compelling reason to change it and Luis & Hilarie are ok
including such a change in our editorial update, I don't have a problem with
it.  Jamie, I think Intel asked for this simplification; comments?

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 19 Apr 2002 09:38:34 -0700

>>>>> On Thu, 18 Apr 2002 18:38:22 -0400, "Lee Rafalow" <[email-masked]> said:

Lee> If there's a compelling reason to change it and Luis & Hilarie
Lee> are ok including such a change in our editorial update, I don't
Lee> have a problem with it.  Jamie, I think Intel asked for this
Lee> simplification; comments?

I think it would be a good thing to do.  Right now, nearly all the
classes are fairly reusable (ie, actions, filters, conditions, etc)
*except* rules which seems a bit odd.  An example usage would be two
different groups assigned to two different endpoints, but each should
contain a specific rule after the endpoint-specific-rules had been
ruled out.  (I thought about trying to use the word "ruler" as well in
that sentence, but it just didn't work).

-- 
Wes Hardaker
NAI Labs
Network Associates