Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Mar 2004 21:18:59 +0200

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. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules.  

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Randy Presuhn
> Sent: 17 March, 2004 8:55 PM
> To: Disman (E-mail)
> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> 
> 
> Hi -
> 
> I'd welcome discussion of this on the disman mailing list.
> I think it's relevant to the question of what to do about the
> expression and event MIBs.
> 
> Randy
> 
> > From: <[email-masked]>
> > To: <IETF-Announce:>
> > Sent: Wednesday, March 17, 2004 8:10 AM
> > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> >
> 
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >
> >
> > Title : Advanced History Collection Framework
> > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar
> > Filename : draft-yadawad-disman-ahcf-00.txt
> > Pages : 47
> > Date : 2004-3-17
> >
> > This draft defines a portion of the Management Information Base for
> >     use with network management protocols in TCP/IP based 
> Internets. In
> >     particular, it defines objects for configuring and 
> controlling the
> >     history collection of user specified Data, which is an ASN.1
> >     INTEGER based object.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt
> >
> ...
> 
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Mar 2004 12:14:07 -0800

Hi -

(as technical contributor)

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Disman (E-mail)" <[email-masked]>
> 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.

> I think that it would help the discussion if the authors could shortly describe
> what is the added value that this MIB module would bring, and what

Agreed.

> operations/management functions this MIB module provides that are
> not covered by existing MIB modules.
...

To the extent that the script MIB supports languages that are Turing
complete, one could reasonably argue that all other MIBs are superfluous.
Of course, a problem with such a line of argument would be the
amount of pain required to use such a system.  That is why the expression
MIB and the script MIB were both put out as Proposed Standards.

The motivation for the expression MIB was that it was supposed to be
simpler to implement and use.  Whether it adequately met those
criteria is being questioned.  From my perspective it looks like
draft-yadawad-disman-ahcf-00.txt presents another factoring of
the problem.  I am far from convinced that it is *the* solution, but
(as WG chair) I think it's appropriate to include it in the discussion
of whether the expression MIB requires some re-thinking.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 17 Mar 2004 12:14:07 -0800

Hi -

Agreed.

...

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Mar 2004 12:43:11 -0800

HI,

I just quickly scanned the document. It does provide in creative ways
features not found in other MIB modules. These include:
  1) automatic inclusion of values of new instances that come
     into existence after control entry creation
  2) filtering based on instance
  3) identification of instances via "alternative indices" 

The definitions do have problems, maybe all are fixable. And it
might be easy to extend it to provide additional benefits at a
low cost.

To support it might be pretty expensive in memory and CPU processing,
and it appears to be best matched for monitoring "hosts" or
"big routers".

>of whether the expression MIB requires some re-thinking.
Regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 17 Mar 2004 12:43:11 -0800

HI,

Regards,
/david t. perkins

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 23 Mar 2004 15:23:46 +0100

Randy and all,

> overview of  http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt

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-masked]        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]

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 23 Mar 2004 15:23:46 +0100

Randy and all,

    Juergen

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