[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



...living in a country blessed with a lot of sun, I must use protecting
covers for the driving wheels. What I have observed, is that despite the
fact that there seems to be no standard for steering wheels, their form and
diameter have enough commonality to allow for the same cover to be used for
my last three different models of cars. 

One more reason for supporting the point made in the message by dbh.

Regards,

Dan


> -----Original Message-----
> From:	David Harrington [SMTP:dbh@enterasys.com]
> Sent:	Thu January 18 2001 21:33
> To:	snmpconf@snmp.com
> Subject:	Re: snmpconf 11. Setcli accessor function - Item to be
> resolved on email  list
> 
> Hi,
> 
> I am a real evangelizer for standards, but sometimes must deal with
> reality.
> 
> 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()
> function. 
> 
> 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
> dbh
> 
> 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