[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 am a real evangelizer for standards, but sometimes must deal with

If my car manufacturer provided me a car that didn't have a steering
wheel because the industry hadn't yet set a standard for steering
wheels, I wouldn't be able to use the car, no matter how well it
complied with those standards that did exist.

If we provide a configuration mechanism that can only manipulate SNMP
MIB objects, then snmpconf may be unable to apply customer policies to
existing devices. Most devices are still configured more via CLI than
SNMP. If we don't support a CLI "gateway", then operators cannot
translate high-level policies into available configuration commands. 

The ideal solution, of course, is to expand the number of SNMP objects
to include all functionality of managed devices, but it isn't very
realistic to expect that this will happen soon. We should provide a
migration strategy that allows for configuration of existing devices,
and encourages development of additional mib modules.

I think it is important, albeit distasteful, to provide the ability to
integrate SNMP and CLI and possibly other existing mechanisms to
configure devices to meet customer policies. The current proposal calls
for a setcli() function; maybe this should be expanded to a more generic
execute_this_non-snmp_command() function, i.e. we need a system()

If we don't support some type of system() function, then we should
define an SNMP octet-string object that can be SET to a non-snmp command
and executed as part of an snmpconf rule, although I think this approach
might be very inefficient.

my $.02

Jon Saperia wrote:
> On observing the exchange between Joel and Jeff and in the absence of
> other comments, I have not seen a lot of support for the idea and while
> I think Jeffs points are helpful, they fix things that really are not
> issues today (that I know of) but might be if we were to introduce this
> feature.
> /jon
> >
> > >I must be missing something.   I do not understand the value of our
> > >standardizing "the name of the function and the minimum error
> > >behavior".  Given that the parameters will be different for different
> > >systems, having the name the same actually seems almost
> > >counter-productive.  It certainly does not seem like something we should be
> > >puttting time and energy into at this point in the process.
> >
> > one of us is missing something but it may be me
> >
> > here is a bit more about what i was thinking ...  if one has an
> > implementation-specific feature, like we are discussing, one error
> > that i think is likely to happen in practice is that somebody will
> > download and attempt to run a script for a flintstone router onto a
> > yogiberra router
> >
> > if the names of the accessors and the minimum error behaviors are not
> > standardized, then you get a generic error that is indistinguishable from
> > a language syntax error, e.g., a typo and any recovery is impossible
> >
> > if, however, you have a standard for the accessor, you can define minimal
> > error behaviors like
> >       no cli subsystem
> >       cli syntax error
> >       and the like (perhaps more, perhaps not)
> >
> > then, a prudent coder can do some defensive driving against these common
> > errors as we have been taught to do (but do all too seldomly)
> >
> >       [i am aware that you could achieve the same result via use of an
> >       additional generic accessor function similar to the c-shell operator
> >       " -e " for file inquiries, but this seems to be an unnecessary and
> >       unwarranted complexity unless justified elsewhere and that seems
> >       pretty unlikely]
> >
> > i think that the diagnostic benefits of an error mechanism that is more
> > specific and localized to the the problem rather than less specific are
> > uncontroversial, but, then, i thought that the above was uncontroversial
> >
> > if this turns out to be real contentious, i am reluctantly willing to
> > duck and cover in the interest of timely progress on other issues
> >
> > perhaps if i had not been prevented from being able to join you in san diego,
> > i would be better equipped and able to anticipate how controversial this
> > might be
> >
> > regards,
> > jdc
> >
> Thanks,
> /jon
> --
> Jon Saperia                  saperia@jdscons.com
>                              Phone: 617-744-1079
>                              Fax:   617-249-0874
>                              http://www.jdscons.com/

David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA