Usability of Expression MIB (was: Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt)

Juergen Quittek <[email protected]>
Newsgroups gmane.ietf.disman
Message-ID <2147483647.1080055426@[10.1.1.171]>
Randy and all,

--On 17.03.2004 12:14 Uhr -0800 Randy Presuhn wrote:

> Hi -
>
> (as technical contributor)
>
>> From: "Romascanu, Dan (Dan)" <[email protected]>
>> To: "Randy Presuhn" <[email protected]>; "Disman (E-mail)" <[email protected]>
>> Sent: Wednesday, March 17, 2004 11:18 AM
>> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
>>
>
>> I will repeat a comment that I made during the meeting in Seoul. I think that all,
>> or almost all that is being defined in this MIB module can already be performed
>> - some features even in multiple ways - by agents that implement existing MIB
>> modules like RMON, Events MIB, and Alarm MIB.
>
> This seems to be the case.  I think the question raised is one of usability,
> that is, how difficult is it to configure these existing MIBs to these things.
> This is another facet of the old scripting vs. expression vs. special-purpose
> MIB debate, but also ties in with the questions Juergen raised in his
> overview of  http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
> at the session in Seoul.

Usability of the Expression MIB was exactly our starting point for the
development of the Check MIB.

As I explained  (at least I tried to) in Seoul, we wanted to implement
local health checks on small devices.  In particular, we wanted to
(1) compare a (configurable) set of managed objects to thresholds or
desired status values, (2) summarize the results and (3) send
notifications on the summary in case of failed checks.
(See more details in <ftp://ftp.ccrle.nec.de/pub/disman-check-mib-ietf59.pdf>

This is well possible using Expression MIB and Event MIB.
However, when we started implementing it, we discovered big
overheads on the side of the agent (number of tables and objects)
as well as on the side of the manager (number of get and set requests
required for configuring a health check).

This is a usability problem.  When discussing the Event/Expression MIB
solution with product management people in my company, they said no
because the cost/benefit relation was not acceptable for them,
particularly not on the small devices which are our target for local
health checks.

As an alternative, we developed the small Check MIB which just has
5 scalar and 16 columnar objects (see MIB tree at the end of this
email) but still is general enough for supporting a wide range of
different health checks on a wide range of devices.  Also configuring
checks on the manager side became many  times less complex than for
Expression/Event MIB.

My conclusion concerning the Expression MIB:

Usability is poor although (or because) functionality is very good
and general.  It is designed multi-purpose, but for our purpose
(and potentially also for other purposes) it is not well usable.

    Juergen
-- 
Juergen Quittek        [email protected]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de



==============
Check MIB tree
==============

--checkMIB(1.3.6.1.2.1.7777)
  |
  +--checkObjects(1)
  |  |
  |  +--checkCapabilities(1)
  |  |  |
  |  |  +-- r-n TimeTicks  checkCapabMinCheckInterval(1)
  |  |  +-- r-n Unsigned32 checkCapabMaxResults(2)
  |  |  +-- r-n Unsigned32 checkCapabMaxRules(3)
  |  |
  |  +--checkControl(2)
  |  |  |
  |  |  +-- rwn Enumeration checkCtrlAdminStatus(1)
  |  |  +-- r-n Enumeration checkCtrlOperStatus(2)
  |  |
  |  +--checkResultTable(3)
  |  |  |
  |  |  +--checkResultEntry(1) [checkResultName]
  |  |     |
  |  |     +-- --- SnmpAdminString    checkResultName(1)
  |  |     +-- r-n SeverityReturned   checkResultSeverity(2)
  |  |     +-- r-n Unsigned32         checkResultSize(3)
  |  |     +-- r-n TimeStamp          checkResultTime(4)
  |  |     +-- rwn TimeInterval       checkResultInterval(5)
  |  |     +-- r-n SeverityConfigured checkResultSeverityThreshold(6)
  |  |     +-- rwn StorageType        checkResultStorageType(7)
  |  |     +-- rwn RowStatus          checkResultRowStatus(8)
  |  |
  |  +--checkRuleTable(4)
  |  |  |
  |  |  +--checkRuleEntry(1) [checkResultName,checkRuleName]
  |  |     |
  |  |     +-- --- SnmpAdminString    checkRuleName(2)
  |  |     +-- rwn ObjectIdentifier   checkRuleOid(3)
  |  |     +-- rwn RuleValue          checkRuleValue(4)
  |  |     +-- rwn Enumeration        checkRuleOperation(5)
  |  |     +-- rwn SeverityConfigured checkRuleSeverity(6)
  |  |     +-- rwn RowStatus          checkRuleRowStatus(7)
  |  |
  |  +--checkFailureTable(5)
  |     |
  |     +--checkFailureEntry(1) [checkResultName,checkFailureSeverity,checkRuleName]
  |        |
  |        +-- --- SeverityReturned checkFailureSeverity(1)
  |        +-- r-n ObjectIdentifier checkFailureOid(2)
  |
  +--checkNotifications(2)
     |
     +--checkEvent(0)
        |
        +--checkFailed(1) [checkResultSeverity]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.