[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Agent Capabilities and sysORTable


"Thomas, Steven C (Steve)" wrote:
> My question is:  Why don't most agents (I haven't found any so far)
> implement or at least populate the sysORTable?  Is there some hidden
> difficulty in implementing it on the agent side?  Or have I misunderstood
> the purpose of sysORTable?

Whatever the reasons, the fact remains that many
MIB implementors do not populate the sysOrTable
and therefore it is unreliable to use.  We should
try to ensure this doesn't happen again.

> I am not arguing that the protocol capabilities MIB or mechanism isn't
> needed, but I am cautious considering my experience so far with sysORTable.

Any mechanism that advertises an entity's ability to handle std
extensions *probably* is not very problematic, since perhaps this
part could be handled automatically by the SNMP technology (toolkit)
vendor or the small team of people (even in a really big company)
responsible for the product's SNMP infrastructure.

But it's the individual product MIBs that get problematic.  It would
be nice if there was a way where this could also be automated and be
more transparent to the MIB implementor (but maybe not the MIB
designer).  For example (just brainstorming for purposes of
clarification) perhaps each new MIB could declare a VendorFeatures
scalar which the MIB implementor populates with MIB specific feature
info.  Then a std VendorFeaturesTable could simply have one row
(an OID) for each such scalar.  Perhaps the table is populated
automatically in really smart SNMP systems or it's done fairly
transparentally (i.e. the VendorFeatures scalar implementor makes a
call passing the OID to the VendorFeaturesTable at system initialization
or after subagent registration).  Questions as to how subagent protocols
support this would of course arise (i.e. if AgentX had the ability for
subagent-subagent communication, this could be supported, though
another solution would be instance-level registrations of objects of
a certain class where in this case class = VendorObjects).

In any case, SNMP mgrs could then walk the VendorFeaturesTable and
query each scalar independantly, or a MIB-specific mgr appl can just
see if a given scalar is there and get the info it needs.  You'll note
I intentionally avoided the issue of what info is actually in the scalar
(but it could range from simply containing a MIB version indicator to
something much more complex).

An alternative is to define new GetModule and GetNextModule PDUs which
GETs on MIB module OID anchors to retrieve a MIB's LAST-UPDATED info
and/or a bit-mask type of object that is not explicity declared but is
supported by a new kind of module clause, i.e., FEATURES (bitmask),
where each bit represents a specific MIB feature that is fully
or not.  This too could be fairly automatable and easy for individual
implementors to support.

FWIW!  Now I'll head for the bomb shelter :-)