RE: Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
"Romascanu, Dan (Dan)" <[email protected]>
| Newsgroups | gmane.ietf.disman,gmane.ietf.rmonmib |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F056B293E@is0004avexu1.global.avaya.com> |
... and that's fine with me. At this point the right questions are - I think - on the table, and Andy's answer helped by clarifying the issue of the relationship with the existing RMON MIB modules from the perspective of the RMON WG. Let us see what other people have to say, if they have an opinion. Regards, Dan -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Shailaja Yadawad Sent: 22 March, 2004 2:58 PM To: Romascanu, Dan (Dan); [email protected]; [email protected] Cc: [email protected] Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, For a moment I want to focus on getting the WG to understand the need for standardization of the proposed features. I want to seek WG help in deciding either for the new standard or extending the existing standard. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" <[email protected]> 3/18/2004 7:49:00 PM >>> ... 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 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.