[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

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. 


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