Subject: RE: policyRuleDebugMode needed?

From: Andrea Westerinen <[email-masked]>
Date: Thu, 18 Feb 1999 11:21:30 -0800

Comments inline, preceded by [arw].  Bottom line, I think that the info is
useful, needed and should be in the schema - reasons below.
Andrea

-----Original Message-----
From: Chris Martin [mailto:[email-masked]]
Sent: Wednesday, February 17, 1999 4:43 PM
To: [email-masked]
Subject: policyRuleDebugMode needed?

Since we didn't have enough time to cover everything at the meeting, I'd
like to cover one of the (hopefully;) less controversial
questions/comments I had.  This comment concerns the attribute
policyRuleDebugMode (definition at end).

Does it really make sense to have this in the schema?  My first thought
was that 'no' for a few reasons.  I'm not against the <function> (or
"service", if you want to call it that) the attribute provides, but
question the need for putting the attribute in the schema.  I think, as
it is defined right now, it has limited utility.

First, I look at a "debug" or test function as a "volatile" type of
activity.  I just need to test one instance of a policy rule, perhaps.
Since the rule itself can take no actions, I can't have a rule action to
turn my test function off.  This would be viewed as a "one-shot" test
invocation.  I would potentially want to do this.  

[arw] The problem is that a policyRule should always have an Action - either
explicit in a subclass of the Rule or via the ActionList.  Quoting from the
I-D, "For all policy rules, at least one action MUST be specified, either
via the containedPolicyActions aggregation, or defined explicitly within a
subclass of policyRule."  In addition, the assumption behind the attribute
is that you might need to disable actions at any time that you trying to do
debug - when you first create the rule, after deployment when new rules are
introduced and you want to debug the new rules in conjunction with old ones,
when some new state is reached by your system and your rules do not
adequately address the state.  For example, you want to determine which are
firing and what "could" be happening underneath due to the actions, without
the actions actually making changes since they don't "adequately address the
state".  So, in the case of first creating a rule, perhaps I could see
creating it with no Actions and then seeing what happens.  However, in the
cases of existing Rules, I would recommend against de-associating Actions
and then re-establishing them later.  This seems prone to error.

Second, I assume (in
general) the need here is to test something at the PDP level-- and
probably a specific PDP and not all PDPs in general.  Putting a test
reference in at a shared (among PDPs) rule violates this assumption.   I
would also argue that perhaps a "debug" at the policy rule level is
misplaced, and that test points may apply at the policy group or even at
the whole PDP level.  

[arw] You are arguing for conflicting things here.  Debug only at the PDP,
debug at the Group level, debug at the whole PDP level.  I hold that the
right level of flexibility is at the rule level.  Only one or two rules may
be causing problems.  If an administrator wants to disable all the rules of
a policyGroup or of a group of PDPs (maybe based on jurisdiction), then -
perhaps a UI could make this very easy by facilitating this operation.  

Finally, I think having an attribute that
describes a "did execute" as opposed to a "would execute" scenario (aka,
audit?) would be more useful.

[arw] But, where does the administrator make the decision for "did execute"
vs "would execute".  I would hate for PDP or PEPs to decide this on their
own.  This is the purpose of the DebugMode attribute.  

Nothing prohibits implementations from addressing the debug/test
operations outside of the schema through other, potentially more optimal
mechanisms.

[arw] The function of debug is quite normal.  If there isn't a standard way
(ie, an attribute) in the schema - how does any PDP recognize that Actions
should NOT be executed?  This seems a reasonable request to the PDP.  If the
request happens outside the schema - then the PDPs start to get tied to
their policy and admin tools to make decisions like "would execute".  This
would take the PDPs into proprietary extensions for a seemingly "standard"
request.  How else do you address this?

Proposal 1:
Remove the section 5.4.12
[arw] Object for reasons detailed above.

Alternate proposal:
Add the sentence at the end of the (5.4.12) paragraph: "Further
interpretation of the policyRuleDebugMode is beyond the scope of this
document."
[arw] OK, but maybe we should add some of the wording above.

chm

5.4.12  The Attribute policyRuleDebugMode

This attribute indicates that the policyRule should be evaluated, but no

actions taken.  It serves as a debug vehicle when attempting
to determine what policies would execute in a particular scenario, but
not to take any actions to change state due to that
scenario. Further interpretation of the policyRuleDebugMode is beyond
the scope of this document.

The attribute definition is as follows:

  NAME           policyRuleDebugMode
  DESCRIPTION    A flag indicating that the evaluation of the
                 policyRule's policyConditions should occur, but the set

                 of actions specified for the rule should not be
                 executed.
  SYNTAX         Boolean
  OID            <to be assigned>
  EQUALITY       booleanMatch
  SINGLE-VALUED
  DEFAULT VALUE  FALSE

---

From: "Chris Martin" <[email-masked]>
Date: Sat, 20 Feb 1999 13:50:30 -0500

comments inline...

> and then re-establishing them later.  This seems prone to error.

[chm] Hmmm. I wasn't advocating a rule without actions.  I think my phrase"the
rule itself can take no actions" caused the confusion.  I should
have said "the rule will execute no actions".  I don't disagree with
your comments.

> perhaps a UI could make this very easy by facilitating this operation.

[chm] I agree fully with with the last sentence, and almost with the
wholeparagraph;)  I hold that the right level of flexibility is at the rule
INSTANCE level. If I have a general rule that is in the directory that
applies to lots of switches, for instance, I don't want to disrupt lots
of switches by running debug operations.  My testing should be allowed
to be done on one instance (one switch) rather than on the rule.

> own.  This is the purpose of the DebugMode attribute.

[chm] Perhaps I'm thinking about a different type of function. Case in point:I
have 7 rules on my switch. A medium priority rule that I *thought* was
supposed to execute apparently did not.  How do I tell if it did?

> request.  How else do you address this?

As I stated up front, it's not the <function> in question, it's how thedebug is
applied.  I disagree with your statement "how does any PDP
recognize that Actions should NOT be executed?" since by putting it in
the schema you should say "how do *all* PDPs recognize that Actions
should NOT be executed?"

I think your concern about a standard method is reasonable. However, I
don't know how the PDP conveys information about rule instances that
"would execute" to outside management entities.  The format and
interface for this information is not defined.  It seems like this will
necessarily be vendor specific (UI, SNMP, flat file, a sysLog, etc.)
unless it is defined.  I don't think this detail should be in a framework
document.

If we look just at the policy ability to disable a rule, maybe the
policyRuleDebugMode should be coupled with policyRuleEnable (as
David suggested.) Then we can leave the details of how the PDP
disseminates information up to the PDP.  The per policy vs. per
policy instance point is still not addressed with this method, however.

> [arw] OK, but maybe we should add some of the wording above.

[...clipped]