Re: Intended use of SAStaticAction Class

["Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>]

Casey, I haven't looked at the 01 draft in a while but I think you're
misreading it.  Jamie is working on updating it, until then you might want
to take a look at http://rafalow.home.mindspring.com/dmtf.htm for the
preliminary, pre-publication dmtf standard that is being developed in
parallel with the IPSP WG.  In it, the aggregation between SARule and
SAAction (SAActionInRule) establishes the relationship between a rule and
one or more negotiation and/or static actions.  The rules are either IKE or
IPsec rules (there's no such thing as a static rule, only static actions)
and, you're right, a rule can only be in 1 group (but groups can be in
multiple groups).

     +----+
     |    |*               1   *        *    1..n
     +-<> IPsecPolicyGroup <>--- SARule <>--- SAAction
        *                                       ^
                                                |
                                                +- SANegotiationAction
                                                |
                                                +- SAStaticAction


I hope this helps.  Lee


----- Original Message -----
From: "Casey Carr" <caseycarr@xxxxxxx>
To: <ipsec-policy@xxxxxxx>
Sent: Tuesday, January 02, 2001 1:05 PM
Subject: Intended use of SAStaticAction Class


> I would like some guidance on the intended use of SAStaticAction classes.
> The intended use of these classes does not appear to be as well described
in
> "draft-ietf-ipsp-config-policy-model-01.txt" as the SANegotiatedAction
> classes.
>
> My question is with regard to the SAStaticAction classes associated with
> SARule classes.  The IPSecRule and IKERule are explicitly shown as
> composited associations contained by the IPSecPolicyGroup.  That is to say
> that instances of the SANegotiatedRule class can be contained in one and
> only one PolicyGroup.  However, there is no equivalent class for static
> rules (i.e. SAStaticRule).  Therefore, to associated a Rule with an
> SAStaticAction we must rely on the more generic PolicyRule.  This
> association does not explicitly state that a PolicyRule can be with one
and
> only one PolicyGroup.
>
> If I we are to implement this model as stated, I believe I am required to
> allow PolicyRules to be associated with more than one PolicyGroup.  I
would
> be required to do this just to support associations of SAStaticAction
> classes with rules.  This seems to be exactly opposite what was intended
for
> the SANegotiatedRules.  Is this the intent or am I missing something?
>
> I would propose the following relationship be added to the model.  This
> seems to me more in line with the intended associations between SARule
> classes and IPSecPolicyGroup classes.  I added the SAStaticRule class and
a
> composite association with IPSecPolicyGroup.
>
> Thanks for your consideration.
>
> Casey
>
>
>
>
>
> Shop Safely Online Without a Credit Card
> http://www.rocketcash.com