[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



Hi DD,

Religious standardization is nice - I frequently practice it myself -
but we need to solve the real-world problems of our customers or our
solution simply won't be useful.

For the snmpconf standard to be accepted, we need to convince users to
use it, but even more importantly we need to convince device vendors to
support it in their products. We will need to convince every vendor to
make all their products completely policy-manageable using strictly SNMP
objects. After twelve years of trying, the SNMP community hasn't even
achieved the goal of making it possible to just monitor using strictly
SNMP yet, never mind having it all based on standardized mibs. 

What makes you think that suddenly the industry is going to reverse
itself and believe that all their devices should be totally manageable
using SNMP objects, to the point that the CLI won't need to be supported
to configure devices?

dbh

"Durham, David" wrote:
> 
> I would like to add my voice to the chorus dismissing a setcli accessor
> function as a *REALLY* bad idea.
> 
> David, we are here to do the right thing from the perspective of promoting
> real standards. Promoting this subversive "ugly hack" runs exactly to the
> contrary of that goal. Allowing the current bad habits to continue under the
> guise of a standard is akin to providing all the booze you want to drink at
> the local alcohol rehab center.
> 
> -Dave
> 
> > -----Original Message-----
> > From: David Partain [mailto:David.Partain@ericsson.com]
> > Sent: Monday, January 22, 2001 5:23 AM
> > To: snmpconf@snmp.com
> > Subject: Re: snmpconf 11. Setcli accessor function - Item to
> > be resolved
> > o n email list
> >
> >
> > Howdy all,
> >
> > Co-chair hat off, techie hat on (I have one here somewhere...).
> >
> > When the idea of the setcli() (or system() or whatever) came
> > up, I was quite opposed to the idea.  It's an ugly hack (just
> > like the "system" system call is), and it, in some sense,
> > subverts the goal of this work.  We don't _want_ to write a
> > different policy script for every different kind of device we
> > have in our networks.
> >
> > Then I got blind-sided by reality and changed my mind.  The fact
> > of the matter is that much of what you want to configure with
> > policy scripts cannot be twiddled with using SNMP.  This is
> > unfortunate, but it's also true.  We can choose:
> >
> >  - to accept the reality and say that, nonetheless, doing things
> >    with SNMP objects is the Right Thing to Do.  This means that
> >    standards organizations and enterprises will need to get to
> >    define the appropriate objects and include agents that allow
> >    you to do sets to those objects
> >
> >  - to accept reality and say that because it is reality, we're
> >    going to put in a "short-term" mechanism that allows you to
> >    change the device using existing configuration mechanisms.
> >    One of the most common ways is via a CLI, so the initial
> >    suggestion was that.
> >
> > 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.
> >
> > With kind regards,
> >
> > --
> > David Partain                  David.Partain@ericsson.com
> > Ericsson Radio Systems AB      Tel:    +46 13 28 41 44
> > Research and Innovation        Fax:    +46 13 28 75 67
> > P.O. Box 1248
> > SE-581 12  Linköping, Sweden
> >

-- 
---
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