[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



Given that even with setcli the scripts will have to be customized, the 
answer to "how do we do this now" is one small step short of standardizing 
setcli.  We recognize that vendor extensions are inevitable.  We document 
(as with SNMP) where vendor extensions go so that they do not colide with 
standard items (it does not matter in this case if they colide with another 
vendors extensions).  And we leave it at that.  If the vendor decides that 
setcli (or system, or ...) is the right answer, they can do that.  If they 
decide that some more specific escape functions are what are needed, they 
can do that.  And the question of how the mechanisms should itneract with 
both the standard SNMP security and the vendor's own security mechanism is 
then clearly up to the vendor.

After all, there is no way we can mandate a useful setcli function when we 
can not say what it will do.  So putting setcli in the spec does not 
actually ensure that the vendors give the users sufficient hooks to 
actually solve the problem.

Yours,
Joel M. Halpern

At 12:50 PM 1/23/01 +0000, David Partain wrote:
>Greetings,
>
>David Durham wrote, regarding setcli():
>
> > 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.
>
>On a fundamental level, I _absolutely_ agree with you.
>What I don't know how to do, given what you write, is how
>to solve the _immediate_ problem of managing very complex,
>large networks with IPsec/diffserv capabilities.
>
>Assuming we do not add setcli(), how are we going to be able to
>deliver products which can be used to networks that exist today?
>Because I couldn't answer that question to my own satisfaction,
>I grudgingly accepted the idea of a setcli().  I'd be thrilled
>if there were another answer.
>
>I would also note that having a CLI driver is exactly what most
>"policy-based management" systems today use for configuring a
>large subset of the devices that exist today.  This is no worse
>than that, and, in my opinion, is a step forward by integrating
>the SNMP capability that we have and is being added.
>
>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