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

Re: snmpconf 11. Setcli accessor function - Item to be resolved o n email list

At 01:22 PM 1/22/2001 +0000, David Partain wrote:
>I greatly fear that if we do not adopt the latter of the two,
>with all of its warts, we're going to limit the utility of what
>we're creating very significantly.  I realize it's not pretty
>and breaks some of the fundamental tenets of what we're about,
>but I think we must do what can reasonably be done to include
>this functionality.

For general purpose applicability, it's been our experience that this is 
absolutely true.

Let me give an example I haven't heard articulated before.  Going forward, 
it will be impossible to tune configuration scripts for operation in a 
given environment where a given configuration control, as represented in a 
MIB object, must have its conflicts/coordination with some vendor-specific 
control tangentially covering the same function handled in some agent 
environment.  This could easily show up in the adoption of a new version of 
the agent image which hasn't had updated MIBs either standardized or 
implemented.  I don't think that "wait for the vendor to update the vendor 
MIB and tune the scripts then" to cover that control will work in practice.

I could conjure examples that aren't very far from real world 
conditions--and as far as these "CYA" escape mechanisms go, in our product, 
we've been spooked enough by this risk to have actually extended them into 
two dimensions.  But regardless, in many agents, without a setcli() or 
something like it, snmpconf applicability will be academic at best.

And I've intentionally avoided the more obvious case--whole control 
functions which are essential and not (yet) configurable via SNMP by virtue 
of MIB incompleteness.  I know that's not a situation we want to allow 
proliferation of by providing setcli(), but I think that's a risk we'll 
have to take. Indeed, for many of its good points, one of the big problems 
I see with COPS as a provisioning vehicle is the lack of awareness of these 
issues of integration with legacy (or rather, current :) PEP implementation 
agent architectures.

Does it help at all that setcli() really should be an open ended interface, 
in that it takes a raw character string, and intentionally doesn't specify 
semantics of that string?  Am I being naive?  Since any script with 
setcli() in it will need to be tuned for the vendor environment anyway, I 
think that issues such as execution latency, whether a cli command needs to 
be specified with an end-of-line, or whatever can be deemed as agent 
implementation-dependent.  I think this falls under what Joel called only 
specifying "the existence of a steering wheel and its rough shape"--we need 
little more here to get what we're after.

Now, circa San Diego, I seem to recall that the only open issue here that 
intrigued me was whether we could assume agent feasibility to issue a raw 
textual CLI command as a "loopback" in the agent environment, from the 
point where the setcli() implementation would want to dispatch the 
command.  In other words, are there any potential agent vendors here who 
for some reason have trouble architecturally dispatching a cli command 
internally from the running snmpconf agent?  Perhaps this was resolved, 
forgive my resurrecting the question if so.


Wayne F. Tackabury		Internet: wayne@goldwiretech.com
Gold Wire Technology		Phone: (781) 647-2211, x213
411 Waverley Oaks Rd., Ste 331
Waltham, MA  02452             Cell: (617) 699-6156