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

David,

There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. 

Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources.

Regards,

Dan



> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On 
> Behalf Of David T. Perkins
> Sent: 17 March, 2004 10:43 PM
> To: [email protected]
> Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> 
> 
> 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 
> 
> 
>