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

Dan,
 
Our main objective was easy and automatic configuration. In case of usr
history group, history collection can be configured for any number of
oids of any table for a given control entry, this will break our design
as configuration settings become specific to particular tables. This was
one main reason as why we did not propose extending the usr history
group.
 
Dan, the main thing is easy configuration and also let user configure
only for the desired number of instances which in turn saves the
resource.
 
Regards,
Shailaja.
 

>>> "Romascanu, Dan (Dan)" <[email protected]> 3/18/2004 4:29:51 AM
>>>

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