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

At 06:19 AM 3/18/2004, Romascanu, Dan (Dan) wrote:
>... and this brings exactly the two issues that I am trying to point to: 
>    * as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work? 

For the alarm features:

Hopefully the DISMAN WG will someday finish the Alarm MIB
and other WGs can use it for alarm management instead of
creating yet another ad-hoc alarm feature thrown in with
a domain-specific monitoring MIB. 

For the threshold wildcard features:

Although this MIB appears to overlap the Expression MIB,
it's much easier to use and it's focused on the persistent
index problem, not the on-the-box data reduction problem.
This MIB is a well-designed band-aid for the (lack of)
persistent index problem.

Unfortunately, the persistent index problem impacts application
polling even worse than embedded polling.  Customers are
demanding that we get rid or our arbitrarily renumbered integer 
index objects (like ifIndex and entPhysicalIndex) by making the
index assignments persist across reboots.  So that's what
we're doing -- addressing the core problem.

>    * assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs?
You are thinking of perhaps adding the threshold wildcard
feature to the usrHistoryControlTable and usrHistoryObjectTable,
and leaving the data (usrHistoryTable) untouched?
Unless there is massive interest from the RMONMIB WG to
re-open the RMON-2 usrHistory group for this feature,
I don't think this approach is viable.

> 
>
>Regards,
>
>Dan

Andy


>-----Original Message-----
>From: [email protected] [mailto:[email protected]]On Behalf Of Shailaja Yadawad
>Sent: 18 March, 2004 12:40 PM
>To: Romascanu, Dan (Dan); [email protected]; [email protected]
>Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
>
>Dan,
> 
>>I was not going that far, and actually I did not have the expression MIB in mind. 
>Expression MIB can be modified based on some of our features.
>
>>What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated.
>
>you are correct that our draft contains object definition similar to that of  RMON alarm and usrHistory but with additional features and changes.
> 
>Regards,
>Shailaja.