Re: policy model Q, SARuleInPolicyGroup::GroupComponent

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 protected]>
To: "'Lee Rafalow'" <[email protected]>
Cc: "Jason, Jamie" <[email protected]>
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
>
> -----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
> >
>
>