RE: policy model Q, SARuleInPolicyGroup::GroupComponent

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 protected]]
> Sent: Thursday, April 18, 2002 3:38 PM
> To: [email protected]; 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 protected]>
> To: <[email protected]>
> 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 protected]
> > NAI Labs
> >
> 
>