| There is a DECnet Phase IV MIB that was written by Jon Saperia (of
ASDS), which should be used by routers that support DECnet. As more
MIBs get written, more parts of routers will be able to provide
management via SNMP. Console support will probably still be needed for
a long time though. Binding the telnet application to the operations
menu - and providing scripting support (ala MSU V1.1) would be useful
for MCC.
bill
|
| You asked several questions. 1.) what is available via SNMP with DECmcc
specifically. 2.) what is available via SNMP generally. 3.) what are
the theoretical limits of SNMP.
The example you gave was for a particular implementation (PROTEON)
which
for the current agent implementation only uses SNMP to examine but
not modify the IP attributes defined by the standard MIB. The
agent implementers choose not to implement Sets (ie. modify). That
is not a limitation of SNMP, it is a limitation of the various
agent implementations.
In general, SNMP is capable of examination and modification of any
set of MIB variables, either standard, experimental, or enterprise
specific. The protocol is sufficient and robust. Most of the
restrictions become apparent when you start to model complex things.
The IETF SMI is the limiting factor, not SNMP. The IETF SMI is clumsy
in that it forces enterprise specific mibs for multiple different
objects to be compressed into a single mib for all the various
products that vendor wants to support. In addition, the containment
structure is very limited as is the table support. The concept of
child objects of child objects doesn't exist nor can tables be defined
within tables. This results in some bizarre structures which makes
application development hacking at best. The larger the volume of
MIBS which use this SMI, the bigger the problem.
Another limiting factor is the lack of conformance to the protocol and
to the MIBs by the various vendors. The recent Network World article
on the lack of conformance by the hub vendors only scratches the
surface. You can't develop an application against the standard MIB
and expect it to work against an object which claims conformance to
the MIB. That is because the objects feel free to not implement a
standard variable and expect applications developers to right huge
amounts of special case code to make up for their lack of conformance
to the standards.
CMIP only solves the capability to provide a more rational model for
objects. The OSI SMI is more capable and IETF would be advised to
use SNMP with the OSI SMI to solve some of their problems.
When you say CMIP, what do you mean? Do you mean the holy grail that
has been a goal for 15 years? If so, it may never arrive. However,
if you mean a specific version. We have been using CMIP for several
years now. It allows you to deal with more complex objects than the
IETF SMI does. That is why DNA5 has over 2000 attributes today with
the number of child entities above 110 and climbing.
However, there is a price to pay. CMIP does justify huge amounts
of CPU cycles, memory, and bandwidth. An equivalent CMIP structure
for a get request takes more space to encode all the OIDs than does
SNMP.
You get what you pay for.
wally
|