Last minute suggestions...

[mccreary@pch.net]

I wanted to add some more rationale for the argument that any management
protocol be independent of its transport mechanism.  From my point of view,
the most important aspect is that it be implementable over many existing
mechanisms (e.g. telnet, ssh, tftp, or a direct serial connection) with the
idea that this provides robustness against partial infrastructure failures.
One of the first issues I think of when looking at a management system is how
much support it requires to operate.  If your management system requires a
significant amount of your infrastructure to be up before it can operate,
then it is likely to be useless in a crisis.  The craft port example is the
last ditch case we often depend on, since it will work even if the net itself
is down.

We need to differentiate between the syntax of a management protocol and a
user interface.  Specifying the management protocol is not specifying a UI,
but choosing ASCII as a data representation and the same command/response
semantics as a CLI make the protocol less dependent on other resources in a
crisis.  If the protocol uses an encoding and syntax that is human-readable,
then it can be used in the last ditch scenario when everything else is
broken.

On the other hand, arbitrarily complex user interfaces can be built regardless
of the back-end protocol used.  Continuing the analogy Bill suggested, SMTP
doesn't have anything to do with how email is processed, stored, or viewed,
but it supports very complex interactions between MTAs.

On another track:  MIB objects are often at so low a level that they make
configuration tasks unnecessarily complex.  I remember trying to configure
VLANs on switch with SNMP, and just creating a new port group required three
SNMP sets.  The switch's agent required all three sets to be in a single
packet or it would reject them, presumably so all three changes could be made
atomically.  This relates to the issues about how to group changes (multiple
workspaces, etc.), but it doesn't make sense to provide managment commands
at a finer granularity than the device can accept individually.
--
Sean McCreary                                                 mccreary@pch.net