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

From: "Shailaja Yadawad" <[email-masked]>
Date: Thu, 18 Mar 2004 03:41:55 -0700

Dan,
 
As mentioned in the draft following are the features 
 
Simple configuration and Instance Management : suppose if the user
wants to configure history collection for all the instances of the
columnar oid, using RMON object definition the  user has to configure
for each instance individually where as using our object definition, it
is just one configuration setting.
 
It has to be noted here that the user has the option of applying same
configuration settings to all the instances or can fine tune the
configuration setting for desired instances.
 
RMON2 user history object definition does not take care of newly added
and deleted instances and hence if the new instances are added the user
has to configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence it is
important to provide consistent reference of collected history to the
underlying physical media. This kind of feature is seen only interface
group however if user needs this kind of ability for any oid that is
being trended.

Instance Filtering
 
Istance filtering is not available in RMON user history mib.
 
Threshold Monitoring

Yes, threshold monitoring is available in the alarm table but if user
wants a complete solution of history collection and threshold monitoring
in a single object definition, our mib definition provides the
solution.
 
Dan, see it this way, the above mentioned  features are seen in many
mibs but user needs one mib which has all required features as otherwise
it is difficult for the user to implement multiple mibs for one
problem.
 
Regards,
Shailaja.

>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 12:48:59 AM
>>>

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. 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 operations/management functions this MIB module
provides that are not covered by existing MIB modules.  

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Randy Presuhn
> Sent: 17 March, 2004 8:55 PM
> To: Disman (E-mail)
> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> 
> 
> Hi -
> 
> I'd welcome discussion of this on the disman mailing list.
> I think it's relevant to the question of what to do about the
> expression and event MIBs.
> 
> Randy
> 
> > From: <[email-masked]>
> > To: <IETF-Announce:>
> > Sent: Wednesday, March 17, 2004 8:10 AM
> > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
> >
> 
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >
> >
> > Title : Advanced History Collection Framework
> > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar
> > Filename : draft-yadawad-disman-ahcf-00.txt
> > Pages : 47
> > Date : 2004-3-17
> >
> > This draft defines a portion of the Management Information Base
for
> >     use with network management protocols in TCP/IP based 
> Internets. In
> >     particular, it defines objects for configuring and 
> controlling the
> >     history collection of user specified Data, which is an ASN.1
> >     INTEGER based object.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt
> ...

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Mar 2004 06:27:53 -0800

At 02:41 AM 3/18/2004, Shailaja Yadawad wrote:

IMO, the problem worth addressing in the IETF is the
detrimental effect of arbitrary renumbering of object
instance identifiers after a reboot.  This is a general
problem, not related to DISMAN or RMONMIB.  Perhaps
some ideas in this draft could be used to solve the
general problem.

We have a proprietary solution -- save enough info
in NV-storage (e.g., the ifName or ifAlias) to reassign
the same index values after a reboot and avoid renumbering
"returning" instances altogether. 

Optimizations to the usrHistory group should be done in
a new MIB module without impacting the existing RMON-2
conformance.

Andy

>Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the  user has to configure for each instance individually where as using our object definition, it is just one configuration setting.
> 
>It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances.
> 
>RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually.
> 
>History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended.
> 
> 
>Instance Filtering
> 
>Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution.
> 
>Dan, see it this way, the above mentioned  features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem.
> 
>Regards,
>Shailaja.
> 
> 
>>>> "Romascanu, Dan (Dan)" <[email-masked]> 3/18/2004 12:48:59 AM >>>
>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. 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 operations/management functions this MIB module provides that are not covered by existing MIB modules.  
>
>Thanks and Regards,
>
>Dan
>
>
>
>> From: [email-masked] [<mailto:[email-masked]]On>mailto:[email-masked]]On 
>> Behalf Of Randy Presuhn
>> > This draft defines a portion of the Management Information Base for
>> > <http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt>http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt
>> >
>> ...
>> 
>> 
>> 
>>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Mar 2004 06:27:53 -0800

Andy