Subject: snmpconf Policy MIB: assorted other comments

From: "Robert Moore" <[email-masked]>
Date: Wed, 14 Mar 2001 16:46:11 -0500

I have a few additional comments on the Policy MIB:

1. The meaning of this sentence on p. 7 totally
   escapes me:

     "Because policy code can make policy decisions
      based on the value of any MIB object, role
      strings will typically contain information not
      accessible in MIB objects."

   Could you elaborate and/or clarify?

2. Section 10.1.2.4 needs some editorial work -- it
   looks like the text and the examples must be
   based on a previous version of searchcolumn.

3. In Section 10.1.2.6 (right at the end), I think
   you need to say something like "An implementation
   MUST discard stored counter values upon detecting
   a counter discontinuity."  Otherwise you'll be
   getting a rate based on an invalid counter delta.

4. In Section 10.1.3.4, the use of the terms "pdu"
   and "varbindlist" is confusing.  In the first
   sentence, for example, what is "the specified
   varbindlist"?

5. Section 10.3.2 (editorial): is the first argument
   "capOid" or "capability"?

6. Section 10.3.7 (editorial): the order of the
   arguments in the examples doesn't match their
   order in the function definition.

7. Section 10.4.4 should say what happens if 'n' is
   too big.  My guess is that the comparison would
   just return the right answer anyway.

8. Section 10.4.8: an example would make me much
   more confident that I understand how this is
   supposed to work.

9. pmPolicyPrecedence object (p. 59): the interaction
   with pmPolicyFilterMaxLatency should probably be
   explained a little more fully.  If, for example,
   I've got a policy whose filter is evaluated once
   every 24 hours, and another that's evaluated once
   a minute, is it the first policy's "result of
   record" that matters?  If the once-a-minute rule
   has the higher priority, and the once-a-day rule
   has had its filter evaluate to TRUE for an element,
   what happens as the higher-priority policy's filter
   evaluates to TRUE, then FALSE, then TRUE again
   throughout a day when the once-a-day policy's
   "result of record" is TRUE?  Does its action get
   turned on and off based on whether the latest
   evaluation for the once-a-minute policy was
   FALSE or TRUE?

10. pmPolicySchedule object (p. 60): you exclude 0
   from the range, then use it.

11. pmPolicyFilter object (p.60), possibly some other
   places: in the fourth paragraph you say that when
   the filter returns a nonzero value, the associated
   action *will* be executed on that element.  This
   fails to take into account the fact that
   pmPolicyPrecedence may cause the action not to be
   executed.

12. pmPolicyAdminStatus object (p. 60): The second
   paragraph confuses values of this object with values
   of pmPolicyRowStatus.  Also, the final sentence of
   the third paragraph seems to imply that entries in
   the pmPolicyCodeTable cannot be shared my multiple
   policies.  Is this restriction intentional?

13. pmTrackingPolicyToElementInfo object (p. 86): I
   don't see a way to represent what should be the
   typical case -- the filter matched and the action
   executed successfully.

14. pmTrackingElementToPolicyStatus object (p. 88):
    "Even if the policyFilter later fails for this
    element, this value will stay in the forceOff(2)
    state."  Why would the policyFilter ever be
    evaluated again for this element, if the state
    of this object is forceOff?

15. Notifications (p. 93): why are there
    notifications defined for adding roles and
    capabilities, but none defined for reporting
    their removal?

Regards,
Bob

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