[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Capabilities Question
on 09/20/2000 4:23 AM, Steve Waldbusser at firstname.lastname@example.org wrote:
> Agent capabilities describes the capabilities of the instrumentation
> (i.e. SNMP Agent), is static, and is not accessible by SNMP
> The capabilities describe the capabilities of the managed system, they
> are dynamic, and they are accessible by SNMP retrievals (as well as by
> the capMatch accessor function).
> In particular, you need this functionality if you want your policy
> to know if diffserv is currently supported by the card plugged into
> slot #3.
> Jon wrote the current iteration of the capabilities table so I'll let
> him field your questions about it.
Frank, this is a response to your excellent comments to the PM module. I
have created a new subject line so that everyone does not have to read all
of the other comments. The short answer is that Steve said it well. I have
more detail below.
The capabilities that we use here are not the same thing as what people have
come to understand as capabilities in the AGENT-CAPABILITIES sense. Nor
could this be accomplished with the sysORTable. A much richer set of
conditions needed expression than either of these mechanisms allowed.
There were some questions posed by Andrew Smith some months ago on this list
that led to the current capabilities table in the current form. What the
capabilities table is designed to do is express what a 'system' not an agent
can do. It is also designed to allow the system to express restrictions as
well. For example, if I had a policy that required that parameters be set at
a specific value and the system did not support values in that range, this
could be determined via this table. Please also note that these restrictions
need not be static, that is to say that I can imagine cases where
restrictions might be temporary or change as new software is added or
removed from the system. For example, we need these capabilities to
1. Mechanism specific abilities such as queuing methods supported in the
case of DiffServ or Encapsulating Security Protocol in the case of security.
These objects may not always be visible at the OID level.
2. Restrictions, or or enhancements to basic capabilities. For example
if a standard supported mechanisms 1, 2, and 3 and a vendor had a version
that supported their own mechanism type 4, this would be the way for the
system to 'advertise' this ability. This would be the way that a policy
management application would come to know that a system had
implementation-specific enhancements (or restrictions) Once again, these
abilities are not always going to be static and values in this table could
Hope this helps.
I have attached the exchange between Andrew and myself on this topic. It was
sent to the list on 6/27 so it may have faded from our collective memory.
>> on 06/13/2000 6:09 PM, Andrew Smith at email@example.com wrote:
>>> There are several levels of granularity on which this could work:
>>> 1. Lowest as in "I support the diffServMeterTable", "I do not support the
>> I think the mods above support this.
>>> 2. Slightly higher as in "I support head droppers but not tail droppers"
>> Depends on the layout, but I think this would be handled.
>>> 3. Higher as in "I support head droppers that feed into strict-priority
>>> schedulers but not into WRR schedulers"
>> I doubt very much that this would be correctly dealt with in the objects I
>> wrote. At some point, humans will have to be involved. I would be happy to
>> say we can not deal with this type of condition and that the person writing
>> the 'rule' would have to take this into consideration. Of course this is not
>> an excuse for the agent not doing good error checking :-)
>>> There's also a "number of instances" dimension to it: "I support 3 strict
>>> priority scheduled queues per interface", "I support 3 strict priority OR 2
>>> WRR scheduled queues per interface but not both at the same time".
>> This in my view is a 'capacity' question. A valid one but dealt with
>> elsewhere. We have yet to have a full discussion on this topic, though I
>> look forward to it.
>>> There could also be an even more abstract notion of "I support AF but not
>>> EF" but that's somewhat different (since we don't have an AF or EF MIB -
>>> just one that hacks on the individual components that work together to
>>> provide AF or EF).
>> Since this is not a capability at this level. I am not sure how to deal with
>> this. Of course we could create mechanism specific objects for things like
>> this and they could be modified by this table.
>>> This could get quite fun ... but the more information like this that an
>>> agent can export, the easier will be the job of the manager and the more
>>> multi-vendor this whole config thing can become.
>> Agreed. Of course we have to also make it implementable - some people may
>> feel this table with the 7 objects is already to hard. Others may feel it
>> does not go far enough.