[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Policy MIB: assorted other comments
I have a few additional comments on the Policy MIB:
1. The meaning of this sentence on p. 7 totally
"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
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
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
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
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group