[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Issue #18 resolution - Update capabilities table
> I hope that we can agree that this is a potentially difficult problem.
> However, in the case that you bring up, I believe that one has to run
> a classifier program that probes the managed systems. Of course if you
> have 100 systems, and 30% are brand X, 45% are brand Y, and the remaining
> 25% are brand Z, you don't need to do extensive probing of each of
> the 100 systems for each new management app.
As I explained on the phone, one combines information at the management
station learned from the capabilities tables with other information
known about a device before installing policies. The capabilities table
will let you know if a device can perform DiffServ. Knowing the model
and vendor and sometime even release number are required before a
management application will know what type of policy to install.
> I get a little worried about deploying a new management app (or script)
> on 100 systems at the same time on a live network that I have not tested
> pretty extensively on a single system in a controlled environment.
That is not an SNMPCONF specific issue. Just as one should test things
with CLI based scripts or file transfer based technology so too should
scripts be tested. Seems kind of obvious to me.
> A capabilities mechanism that allows me to skip testing,
> but will fail sometimes (because of approximate completion
> and low precision in its description of capabilities)
> doesn't seem like a prudent addition.
> I've still got to test in my world.
Capabilities does not, nor is it intended - by itself or in
combination with other factors - eliminate the need for testing. It is
good operational practice to test.
> At 03:59 PM 4/20/2001 -0400, Joel M. Halpern wrote:
> >In your description Dave, you state that the management app should "probe the capabilities of the individual device. Given taht what we are trying to do is provide a means my which a common set of configuration can be defined by the administrator, and applied across a number of devices, there is no way that the application can "know" much about what capabilities are required unless the language / libraries / objects tell it so. What we are trying to define are the hooks that make it likely that the policy will be applicable / useful. We recognize that you can not define fine enough grained capabilities in a general fashion. Instead we are trying to provide coarse grained information that will help the management system determine whether a given configuration policy is likely to be useful to send to a given system.
> >Joel M. Halpern
> /david t. perkins
Jon Saperia email@example.com