Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent

From: "Jason, Jamie" <[email-masked]>
Date: Fri, 19 Apr 2002 09:29:02 -0700

If I recall correctly, Vic is correct.

I think that since a rule's priority is now an attribute of the association
between group and rule, there is not a harm in removing this restriction.
However, I will leave it up to Luis and Hilarie to decide if it is okay to
include this change in the minor edits necessary to move this document to
last call.

Jamie

> -----Original Message-----
> From: Lortz, Victor 
> Sent: Friday, April 19, 2002 9:05 AM
> To: 'Lee Rafalow'
> Cc: Jason, Jamie
> Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent
> 
> 
> Lee, I think the cardinality was limited to 1 originally 
> because the priority of a given rule was scoped to the policy 
> to which it belonged.  I'm not sure if the model has evolved 
> since then such that this is no longer important (I haven't 
> been following this closely).
> 
> Regards,
> Vic
> 
> -----Original Message-----
> From: Lee Rafalow [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 3:38 PM
> To: [email-masked]; Michael Baer
> Subject: Re: policy model Q, SARuleInPolicyGroup::GroupComponent
> 
> 
> 
> 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?
> 
> 
> ----- Original Message -----
> From: "Michael Baer" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, April 11, 2002 12:53 PM
> Subject: policy model Q, SARuleInPolicyGroup::GroupComponent
> 
> 
> >
> > 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, 25 Apr 2002 07:47:31 -0400

Victor remembers it differently.  The model has moved on since then so if we
think the restriction should be removed it wouldn't be hard to do so.
----- Original Message -----
From: "Lortz, Victor" <[email-masked]>
To: "'Lee Rafalow'" <[email-masked]>
Cc: "Jason, Jamie" <[email-masked]>
Sent: Friday, April 19, 2002 12:04 PM
Subject: RE: policy model Q, SARuleInPolicyGroup::GroupComponent

> Lee, I think the cardinality was limited to 1 originally because the
> priority of a given rule was scoped to the policy to which it belonged.
I'm
> not sure if the model has evolved since then such that this is no longer
> important (I haven't been following this closely).
>
> Regards,
> Vic
>
> 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
> generality, but the authors agreed early on to the simplifications and no
> one challenged it.
>
> including such a change in our editorial update, I don't have a problem
with
> > >   instances subset and into one IPsecRule instances subset based on
the
PolicyRuleInPolicyGroup
> > >   [1..1] cardinality indicates that a SARule instance may be contained
> > >   in one and only one IPsecPolicyGroup instance (i.e., SARules are not
> > restriction and it seems arbitrarily limiting. So, basically, I wanted
> > to know what are the reasons for choosing a 1..1 cardinality here (as