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

HI,

On the issue of whether or not to extend existing RMOM definitions
or to create new ones is something that I can see both sides.
It appears to me that the new proposal is something that would
be found in a host or big infrastructure box (such as a big router).
In neither of these is a place one would find RMON, and, thus
to me it boils down to a "packaging" issue.

At 12:59 AM 3/18/2004 +0200, Romascanu, Dan (Dan) wrote:
>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 
>> 
>> 
>>