[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
I have a couple of thoughts on the setcli issue.
While what Dave Durham says is true ("Promoting this subversive
"ugly hack" runs exactly to the contrary of that goal"), reality
is that some vendors don't provide adequate mib instrumentation
today, and we (the wg) don't have a sufficiently big bludgeon to
force the issue. We (as a vendor) will have to provide some sort of
setcli accessor function. It would be nice if there were some
aspects about it we can standardize in the interest of portability,
such as the name, arguments, and some error return semantics (be
it as simple as 4 or 5 defined return statuses). I think that no
matter what we do, setcli will be sufficiently ugly that will not
impede progress towards proper MIB instrumentation. Specifying
setcli semantics will enhance portability some in the short term.
For those for whom long term interoperability is a goal, the rest
of the snmpconf work will show the desirability of adequate
SNMP MIB instrumentation for configuration for the medium and long
term. My concern is that without this capability, our work
may prove irrelevant.
Engineer hat, security issue, not well thought out:
One of the concerns about the setcli accessor is the security perspective.
While access is likely going to be rather binary ("yes you can
do setcli", or "no you cannot", regardless of the command to be executed)
access may be governed by creation of a new security model (with perhaps
trivial group names and security levels, or perhaps using these
as arguments to a setcli accesssor function). We might define
an object, accessibility to which governs whether or not a setcli
call would be accepted. Or, as has frequently been suggested, we
can just leave it up to vendors. I am less worried about this than I am
about things like argument type, count, and a few defined return
Jon - did I make it in time for "close of business"?
Steve Moulton SNMP Research, Inc voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197
firstname.lastname@example.org Knoxville, TN 37920-9716 USA http://www.snmp.com