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

RE: snmpconf 11. Setcli accessor function - Item to be resolved on email list

> -----Original Message-----
> From: David Partain [mailto:David.Partain@ericsson.com]
> On a fundamental level, I _absolutely_ agree with you.
> What I don't know how to do, given what you write, is how
> to solve the _immediate_ problem of managing very complex,
> large networks with IPsec/diffserv capabilities.

[Dave] There is the Diffserv MIB, you can use that as a standard set of
managed objects. There are a set of PIBs for managing large IPsec/DiffServ
networks which are also expressed using standards-tract managed objects. 

Basically, with setcli, SNMPConf is: 1. Not using the SNMP protocol for
configuration; 2. Not even utilizing MIB objects for configuration; and 3.
Not providing legitimate standards for configuration. In short setcli
fundamentally violates the charter for this working group. So unless there
is the intention to invert the charter, I suggest that this group focus on
delivering standards based mechanisms for network configuration, and not
backdoor hacks into CLI. 

> Assuming we do not add setcli(), how are we going to be able to
> deliver products which can be used to networks that exist today?
> Because I couldn't answer that question to my own satisfaction,
> I grudgingly accepted the idea of a setcli().  I'd be thrilled
> if there were another answer.
[Dave] Use the standard managed objects that already exist or are coming
into existence. Otherwise invent the ones that are missing (the WG charter
says that's a goal), and/or encourage vendors to expose vendor specific
functionality through private managed objects. If this WG endorses a
backdoor to CLI, this will only work to subvert the standards process, and
discourage companies from exposing device configuration through managed

> I would also note that having a CLI driver is exactly what most
> "policy-based management" systems today use for configuring a
> large subset of the devices that exist today.  This is no worse
> than that, and, in my opinion, is a step forward by integrating
> the SNMP capability that we have and is being added.
[Dave] If SNMPConf can only work via non-standard hacks into vendor
proprietary CLI, then it  becomes painfully obvious that one really can't do
configuration management via SNMP.