Subject: Re: criticality of extended conditions and actions

From: "Mircea Pana" <[email-masked]>
Date: Tue, 24 Jul 2001 14:50:55 -0400

Lee,

I can not find anything that addresses this issue in PCIMe-02. My
apologies if I'm wrong.

Thanks,
Mircea.

"Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote:
> 
> Lee,
> 
> Your proposal sounds good. I've added a few comments in-line and marked
> them <mpana>.
> 
> Thanks,
> Mircea.
> 
> Lee Rafalow wrote:
> >
> > Mircea,
> >
> > Let's break this down into it's component parts:  rule compilation unit of
> > failure and optional rule components.
> >
> > It's difficult for me to imagine that there are sets of rules that can have
> > a rule removed and still somehow reflect the intent of the administrator.
> 
> <mpana>
> The policyGroup can be used to group together other policyGroups and/or
> policyRules under the same administrative role. If the components of the
> group serve different functional domains, the policyGroup itself can be
> thought as a policy bundle.
> Let's consider an example: An organization has edge devices serving
> connections with its (1)customers and (2)providers. These devices
> implement different functions: (1) firewall, (2) QoS, (3) encryption.
> One way of bundling the policies may be:
>    Group1: role=customer
>      Rule1: if TrafficToInternetExceptSomeSites then Firewall-Allow
>      Rule2: if Mon-Fri AND 08:00-17:00 then QoS-HighPriority
>      Rule3: if TrafficToOrFromBank then VPN-Encrypt
>    Group2: role=provider
>      etc.
> Therefore, Group1 is applicable to all the firewalls, QoS interfaces,
> VPN gateways that serve the role "customer". There may be different PDPs
> per functionality and/or PDPs combining some or all functions. The fact
> that the QoS PDP/PEP does not support Rule1 and Rule3 should not stop it
> from enforcing Rule2.
> However, if the policyGroup is not suitable for such use, then may be we
> should define a separate policyBundle that is allowed to span across
> functional domains. Is this in scope for the Policy WG?
> </mpana>
> 
> > So I think that the unit of failure should be the whole aggregated set of
> > rules.
> 
> <mpana>
> I understand the reason behind this but I'm not comfortable with its
> potential impact on the network. There should be an easy way to evaluate
> the impact * before * it happens.
> </mpana>
> 
> >
> > Your example does, however, raise a good point about extending sets of
> > actions.  (I still don't see this extending to conditions, however.) It
> 
> <mpana>
> How about a condition like this:
> (SourceOSIAddress = X25Value)
>  OR (SourceIPAddress = IPv4Value)
>  OR (SourceIPAddress = IPv6Value)
> loaded/evaluated by a device with no X25 support. Should the rule (or
> the entire aggreg.) fail? How about a device that only implements IPv4
> (no IPv6)?
> </mpana>
> 
> > seems reasonable to me that we could define a boolean in PolicyAction that
> > indicates that a recognition failure for a given action instance does not
> > constitute a compilation failure.  (Actually, this should really be a class
> > variable, but we don't have class variables in our model.  CIM has
> > qualifiers that can serve as class variables but they're a clumsy
> > substitute.)
> 
> <mpana>
> I'm happy with the instance variable, it gives more control to the
> administrator.
> </mpana>
> 
> >
> > How's this?
> >
> >   NAME         MayIgnoreAction
> >   DESCRIPTION  This boolean may be set to indicate that an
> >                action instance may be ignored by rule engine.
> >                Actions that may be ignored extend the actions of
> >                a rule but, if not supported, may be ignored and
> >                do not cause the set of rules to be rejected by
> >                the PDP or PEP.
> >   SYNTAX       boolean
> >   DEFAULT      false
> >
> > Implementations MAY support the property.  If not supported and an action is
> 
> <mpana>
> Sounds good but...
> What if we make it: "implementations SHOULD". The reason is that
> implementations that do not support this flag can hardly share data with
> other similar ones.
> </mpana>
> 
> > not recognized by the implementation, the aggregation of rules (we need a
> > name for this thing) is rejected as in other rule parsing errors.
> >
> > This would permit the extensibility you describe in your example without
> > compromising the integrity of the policy.
> >
> > Lee M. Rafalow
> > Voice: 1-919-254-4455; Fax: 1-919-254-6243
> > IBM Internet Technology Management
> > IBM Corporation
> > P.O. Box 12195, BRQA/502
> > RTP, NC 27709 USA
> > Alternate email: [email-masked]
> > Home email: [email-masked]

---

From: "Robert Moore" <[email-masked]>
Date: Wed, 25 Jul 2001 09:19:36 -0400

Mircea,

Lee is on vacation until the start of the IETF on
August 6, so I don't expect him to respond to you
before then.  You're definitely right that this
property did not make it into PCIMe-02.  What I don't
know is whether Lee just forgot to give it to me, or
whether, after discussing it with some of the other
PCIMe and ICIM authors, he decided not to add it.
I'm also not sure about what his intentions were for
the more general text updates.

At this point the best we can do is to add this to
the PCIMe-02 part of the agenda for London, and
discuss it there.  If Lee gets *very* bored on
vacation, he might log on, see this, and give you
a response on the mailing list prior to London.
But I'd be very surprised if he did this - believe
it or not, he finds touring Europe more fun than
Policy modeling:-)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

"Mircea Pana" <[email-masked]>@raleigh.ibm.com on 07/24/2001
02:50:55 PM

Please respond to "Mircea Pana" <[email-masked]>

Sent by:  [email-masked]

To:   Lee Rafalow <[email-masked]>, IETF Policy
      <[email-masked]>
cc:
Subject:  Re: criticality of extended conditions and actions

Lee,

apologies if I'm wrong.

Thanks,

Mircea.

"Pana, Mircea (M.) [EXCHANGE:CAR:5E20]" wrote: