Subject: snmpconf Updated PM MIB draft

From: Steve Waldbusser <[email-masked]>
Date: Wed, 13 Jun 2001 21:25:23 -0700

You can look at the latest version of the PM MIB at
http://www.nextbeacon.com/pmmib/pm.txt

I believe the following items are now closeable:
    2, 5, 14, 19, 23, 26, 27, 28, 29, 30, 31, 32, 33, 34, 37

Here's my change log (the first number is from David's list):
2  Fixed the rest of Bob Moore's comments from his March 14
   email. (Many of these had been fixed earlier.)
   Fixed typos in searchColumn definition
   Added example to oidSplice definition
   Clarified pmPolicyPrecedence
   Fixed bug in pmTrackingEPStatus
-  Fixed typo in pmNewCapabilityNotification
5  Added pmAbnormalTerminationNotification
23 Clarified how to have action taken on policy termination by
   the addition of text to the pmPolicyPrecedence object
27 Wes's #9: added new notification
   Wes's #16: Fixed typo in setVar()
   Wes's #41: Added reference to POSIX
   Wes's #52: Fixed typo in pmPolicyRowStatus
   Wes's #54: Changed index of pmElementTypeRegTable from
              pmElementTypeRegIndex to pmElementTypeRegOIDPrefix,
              deleting the pmElementTypeRegIndex object. Also deleted
              extraneous text about finding duplicates and fixed
              erroneous text about form of the OIDPrefix.
   Wes's #58: Got rid of off(0) enumerated value of pmTrackingEPStatus
              and renumbered remaining enumerations.
   Wes's #59: Can set pmTrackingEPStatus directly to forceOff(1)
   Wes's #61: Specified roll-over rules for pmDebuggingTable and
              recommended timestamp be added to message if available.
30 Added overflow rules for integer arithmetic
34 Suggested that smarter implementations might want to rerun policies
   prior to maxLatency if a role changes (see pmPolicyFilterMaxLatency)
-  Aligned with policy terminology document. To wit: now use the term
   policy condition instead of policy filter

I'll send another draft soon after I've accumulated more changes.

Steve

---

From: David Harrington <[email-masked]>
Date: Thu, 14 Jun 2001 10:08:18 -0400

Hi Steve,

>    prior to maxLatency if a role changes (see pmPolicyFilterMaxLatency)

I believe the object referenced should be pmPolicyConditionMaxLatency.

If I'm an operator, I need to know how this situation will be handled,
and I don't want it to be implementation-specific, I want it consistent
across my network, because it could impact the application of my
security policies. Adding lots of vendor-specific if-then-else clauses
to my policies will make then unwieldy, potentially unreliable, and
difficult to debug and maintain. 

I am concerned that this text doesn't standardize the expected behavior.
I think this language needs to be tightened up to guarantee a consistent
approach by all implementations.
-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA

---

From: Steve Waldbusser <[email-masked]>
Date: Thu, 14 Jun 2001 08:07:24 -0700

Hi Dave,

> I believe the object referenced should be pmPolicyConditionMaxLatency.

You're right.

> approach by all implementations.

Well, the rules for maxLatency has always allowed this sort of leeway
(that's why it's called *max* latency). The new text just suggests a
particular situation in which the agent may wish to use this leeway.

Since we can't know the current value of the filter at every instant of
time, we necessarily rely on a cached value of the last outcome to
perform our logic. The maxLatency objects describe when the cached value
should be considered stale. The policy author can adjust this "cache
timeout" value to meet the needs of the policy. If the policy engine
updates the value more quickly than this, it's a bonus.

Do you think this is OK?

Steve