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

Hi,

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

Andy, you are very correct in pointing out the features of the draft.
Our main motivation
was to provide easy and simple configuration ability to the user and
solving the 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.

I am bit new to IETF and hence could you please point me to some
drafts/standards in this regard.

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

I request both(disman and rmon) WG members to share their thoughts on
our draft.
 
 http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt

Regards,
Shailaja.