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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 18 Mar 2004 16:19:00 +0200

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

Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shailaja Yadawad
Sent: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Mar 2004 08:12:56 -0800

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

>Dan

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Mar 2004 08:12:56 -0800

For the alarm features:

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Mar 2004 09:51:05 -0800

Hi -

(disman WG chair hat on)

> From: "Andy Bierman" <[email-masked]>
> To: "Romascanu, Dan (Dan)" <[email-masked]>
> Cc: "Shailaja Yadawad" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 18, 2004 8:12 AM
>Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
...
> a domain-specific monitoring MIB.

It's already done; it's in the RFC editor queue.

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

Since there is substantial overlap in the membership of the two
working groups, can we confine this discussion to just one of the
WG lists?  I suggest that we continue discussion on the disman
list.  If consensus develops that there is a problem to be solved
along with a general sense  what technical approach we'd like
to use, then Andy and I could consult with Bert (our Area Director)
to figure out whether the work would make sense for either working
group, a new working group, or whatever.

Much of disman's work is a generalization of work pioneered in
the RMON work.  The question of "genericness" (I need a better
word) is the one I personally use in trying to figure out whether
a proposal might make more sense in one WG or the other.
However, let's first decide whether there's a problem to solve
and a general technical direction to use as a starting point for
a solution before jumping to the question putting it on a specific
WG's charter.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 18 Mar 2004 09:51:05 -0800

Hi -

(disman WG chair hat on)

...

...
...

Randy