Re: Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt

David,
 
You have correctly captured the proposed features in our draft.
 
It will be great to fix all the definitions problems that you foresee.

 
Regards,
Shailaja.

>>> "David T. Perkins" <[email protected]> 3/18/2004 2:13:11 AM
>>>

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".

At 12:14 PM 3/17/2004 -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.
>
>> 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
Regards,
/david t. perkins